
USABILITY ENGINEERING 


Also in this issue: 


IEEE COMPUTER SOCIETY 


THE INSTITUTE OF ELECTRICAL AND 
ELECTRONICS ENGINEERS, INC. 


□ Digital Sound 

□ Information Systems 

□ Multidatabase Systems 

□ Dash Multiprocessor 
















































Open unclosed 

CASE 


Searching for the right CASE partner for your organization? 
Once you know what to look for, finding the right partner is 
elementary. All the evidence points to IDE. Its success formula 
combines the right CASE process, tools, training and support 
to make you successful. 


To implement your CASE strategy, start with U. 
the proven choice of software developers. UNIX 
provides the best foundation for multi-user envi¬ 
ronments and offers the widest array of modem 
development tools. Most illuminating. 

Add IDE’s Software through Pictures® and 
your choice of other best-of-class tools such 
as Saber-C, FrameMaker and Interleaf. Software 
through Pictures integrates all these tools with a 
shared repository, supports structured and object- 
oriented methods, and runs over heterogeneous networks 
of Sun, Digital, HP and IBM workstations and X terminals. 

Closed products from other vendors fall far short of IDE’s open 
strategy. Why settle for a 7% solution when you can have it all? 

Look closely at your CASE alternatives and you’ll see why IDE 
is the obvious choice. Only IDE offers you open and extensible 
solutions such as the C Development Environment™ that guarantee 
you can refine your CASE strategies to meet future requirements. 
And if you’re just getting started with CASE, IDE’s Pilot Project 
Package provides all the software, training and support you 
need to make your first project a brilliant success. 

Fortuitous indeed. 


To learn how to create a successful CASE 
strategy for your organization, come to an 
IDE seminar, Or call us for more infor¬ 
mation. We’ll be happy to provide you 
with all the proof you need. 

For more information or to 
register for an IDE seminar in 
your area, call 
1-800-888-IDE1 Ext. 919 
1-415-543-0900 Ext. 919 
E-mail address: sherlock@ide.com 
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SIMULATION BREAKTHROUGH 



SIMSCRIPT II.5 with SIMGRAPHICS 

Simulation models are now easier to build 
--results are easier to understand 


N ow you can provide the users 
of your SIMSCRIPT II.5 
models with SIMGRAPHICS™ 
-graphical input and animation. 

SIMSCRIPT II.5 gives you a 
compact English-like language. 
Your simulation program reads like 
a description of the system you are 
studying. 

With SIMGRAPHICS, results 
are easy to understand-animated 
pictures, histograms, pie charts and 
plots. 

Because your animated simula¬ 
tion results are easily understood, 
your recommendations are more 
likely to be acted upon. 

Free applications booklet 
A new booklet describing suc¬ 
cessful applications of SIMSCRIPT 
II.5® is now available. Typical ap¬ 
plications include: military plan¬ 
ning, manufacturing, communica¬ 
tions, logistics, and transportation. 

SIMSCRIPT II.5 is available on 
most popular computers including 
PC’s and Workstations. 


Free trial offer 

The free trial contains every¬ 
thing you need to try SIMSCRIPT 
II.5 on your computer. 

Try the SIMSCRIPT II.5 lan¬ 
guage, the built-in graphics, the 
quality and timeliness of our sup¬ 
port, and the accuracy of our 
documentation— everything you 
need for a successful project. 

For over 29 years CACI has 
provided trial use of its simulation 
software— no cost, no obligation. 
Act now—free training offer 

For a limited time we also in¬ 
clude free training. Call today to 
avoid disappointment-class size is 
limited. 

For immediate information 

Call Doug Dittrich at (619) 
457-9681, or Fax (619) 457-1184. 

In Canada, call Peter Holt on 
(613) 782-2474, Fax (613) 

782-2202. In Europe, call Nigel 
McNamara, in the UK, on 0276 
671 671, Fax 0276 670 677. 


Rush information on 
SIMSCRIPT II.5 

□Yes, I want to learn the reasons for the 
broad and growing popularity of SIM¬ 
SCRIPT II.5. Act now for free training. 

□ Send the free brochure “Major Applica¬ 
tions of SIMSCRIPT II.5.” 


□ Send details on.your University Offer. 

Return to: Mie comp 

CACI Products Company 

3344 North Torrey Pines Court 

La Jolla, California 92037 

Call Doug Dittrich at (619) 457-9681 

Fax (619) 457-1184 


In Canada: 

CACI Products Division 
200-440 Laurier Avenue West 
Ottawa, Ontario, KIR 7X6 

Call Peter Holt on (613) 782-2474 
Fax (613) 782-2202 
In Europe: 

CACI Products Division 
Coliseum Business Centre 
Watchmoor Park, Riverside Way 
Camberley, Surrey GU15 3YL, UK 

Call Nigel McNamara on 0276 671 671 
Fax 0276 670 677 


SIMSCRIPT II.5 is a registered trademark and service 





















ARTICLES 

12 The Usability Engineering Life Cycle 

Jakob Nielsen 

A usability engineering process to ensure good user interfaces includes elements to be 
considered before the design, during the design, and after field installation of a software 
product. 


Published by 
the IEEE 
Computer 
Society 


Circulation: Computer (ISSN 0018- 
9162) is published monthly by the IEEE 
Computer Society, 10662 Los Vaque- 
ros Circle, PO Box 3014, Los Alamitos, 
CA 90720-1264; phone (714) 821- 

NW, Washington. DC 20036-1903; 
IEEE Headquarters, 345 East 47th St., 



25 SoundWorks: 

An Object-Oriented Distributed System for 

Digital Sound i 

Jonathan D. Reichbach and Richard A. Kemmerer 
SoundWorks lets users interactively manipulate sound through a graphical interface. The 
system handles digitally sampled sounds as well as those generated by software and 
digital signal processing hardware. 

38 Mediators in the Architecture of Future Information 
Systems 

Gio Wiederhold 

Mediators embody the administrative and technical knowledge to create information 
needed for user decision-making modules. The goal is to exploit the data technology puts 
within our reach. 

50 * Taxonomy and Current Issues in Multidatabase 

Systems 

M. W. Bright, A.R. Hurson, and Simin H. Pakzad 
Global access and local autonomy are central to multidatabase system design. This 
article draws on other information-sharing systems research to define key issues. 

63 The Stanford Dash Multiprocessor 

Daniel Lenoski, James iMudon, Kourosh Gharachorloo, Wolf-Dietrich Weber, Anoop 
Gupta, John Hennessy, Mark Horowitz, and Monica S. Lam 
Directory-based cache coherence gives Dash the ease-of-use of shared-memory 
architectures while maintaining the scalability of a message-passing machine. 









DEPARTMENTS 


4 Computer Society Message 

Technical activities within the society 

10 Authentication Revisited 

81 Update 

83 Computer Society News 

Nominations sought for IEEE fellowship 

86 Product Reviews 

Word processors 

94 New Products 

98 IC Announcements 
100 Microsystem Announcements 
103 Conferences 
106 Call for Papers 
108 Calendar 
125 Book Reviews 
128 Open Channel 



Cover: Jay Simpson, Design & Direction 


Career Opportunities, 117; Computer Society 
Information, 127; Membership Application, 
99; Advertiser/Product Index, 80; Reader 
Service Card, 80A 


In the next issue 

Wafer-scale integration 


COMPUTER 

10662 Los Vaqueros Circle, PO Box 3014, Los Alamitos, CA 90720-1264 

Editor-in-Chief 

Jon T. Butler, Naval Postgraduate School 

Associate Technical Editor 

David C. Rine, George Mason University 

Editorial Board 

Dennis R. Allison, Stanford University 

Laxmi N. Bhuyan, Texas A&M University 

Thomas A. Corbi, IBM 

Scott Davidson, AT&T 

Richard Eekhouse, MOCO 

Michael Evangelist, Andersen Consulting 

Scott E. Fahlman, Carnegie Mellon University 

Staff 

Managing Editor: Marilyn Potes 

Staff Editors: Christine Miller 

Chuck Governale 

Bob Carlson 

Linda World 

Contributing Editor: Ware Myers 

Art Director: Jay Simpson 

Design: Toni Van Buskirk 

Production: Chris Patterson 

Ken Duckworth 

John R. Gurd, University of Manchester 

Brent T, Hailpern, IBM T.J. Watson Research Center 

Tadao Ichikawa, Hiroshima University 

Alan Kaminsky, Rochester Institute of Technology 

Yale Pan. University of Michigan 

Guylaine M. Pollock, Sandia National Laboratories 

Norman F. Schneidewind, Naval Postgraduate School 

Vincent Y. Shen, Hong Kong University of Science and Technology 

Martha Sloan, Michigan Technological University 

Will Tracz, IBM 

Akinori Yonezawa, Tokyo Institute of Technology 

Publisher: True Seaborn 

Editorial Director, CS Magazines: Marilyn Potes 

Assistant Publisher: Douglas L. Combs 

Assistant to the Publisher: Pat Paulsen 

Membership/Circulation: Christina Champion 

Advertising Coordinators: Heidi Rex 

Marian Tibayan 

Magazine Advisory Committee 

John Staudhammer (chair), Valdis Berzins, Jon T. Butler, B. Chandrasekaran. 
Carl Chang. Manuel d’Abreu, Dante Del Corso, James J. Farrell III, 

Send 12 double-spaced copies of articles and special-issue proposals to 

Jon T. Butler, Dept, of Electrical and Computer Engineering, Code EG/Bu, 
Naval Postgraduate School, Monterey, CA 93943-5004, 

John A.N. Lee, Peter R. Wilson 

Publications Board 

Harold Stone (chair), Ronald G. Hoelzeman, Mary Jane Irwin, 

phone (408) 646-3299. For electronic submission, Butler's addresses are 

j.butler on Compmai! II and butler@ece.nps.navy.mil on Internet. 

Ming T. (Mike) Liu, Michael C. Mulder, Theo Pavlidis, 

Sallie V. Sheppard, John Staudhammer, KishorTrivedi 











“SSS MESSAGE 


Technical activities within the Computer Society 



Although most volunteers are well 
aware of the significance of the indi¬ 
vidual programs in which they work, 
few have an opportunky-fo see the 
IEEE Computer Society in its entirety 
— as the very substantial enterprise 
that it is. The society has over 100,000 
members. It is the largest society of 
computer professionals in the world, 
and by far the largest constituent soci¬ 
ety within the IEEE. We are involved 
with over 100 conferences each year. 
We publish 12 periodicals, dozens of 
new books, and over a hundred con¬ 
ference proceedings each year. We 
have internationally recognized 
awards, scholarships, local activities, 
accreditation programs, standards de¬ 
velopment groups, and more. 

There is a simple reason why the 
Computer Society has so many activi¬ 
ties: responsiveness to the needs of its 
members. With so many members dis¬ 
persed around the world, it would be 
impossible to serve them without hav¬ 
ing a broad spectrum of activities. 
There are literally thousands of volun¬ 
teers all over the world putting in 
many hours each week to help carry 
out our activities. The Computer Soci¬ 
ety exists because the members find it 
professionally and personally reward¬ 
ing to work in its programs. 

The core of the society’s activities 
comes from its Technical Activities 
Board, which is the focal point for 
much of this volunteer activity. TAB 
currently has 32 technical committees 
(TCs) and several task forces, each 
concentrating on a specific area that is 
a subset of our technology or its appli¬ 
cations. We have TCs on operating 
systems, distributed processing, and 
real-time systems. We work with mul¬ 
tiple-valued logic, personal comput¬ 
ers, microprogramming, supercomput¬ 
ing applications, software engineering, 
security and privacy, and robotics. We 
also study how technology affects cer¬ 
tain groups — for example, the use of 
computers in various fields of medi¬ 
cine, computers in education, and 
computing and persons with disabili¬ 
ties. (A complete list of Computer 
Society TCs follows this message, and 
further information can be obtained 
by using the Reader Service Card.) 


A significant number of the soci¬ 
ety’s conferences originate from with¬ 
in technical committees. Many of our 
books and periodicals were conceived 
within technical committees. The TCs 
are a source of technical output for 
the Computer Society and the profes¬ 
sion. There are also important TAB/ 
TC-related activities our members 
rarely see. For example, a national 
consortium seeking to administer 
grants recently came to the society for 
help in evaluating grant proposals in 
several areas. Referees for those pro¬ 
posals came from our TCs. 

TC membership, one of the many 
benefits of being a Computer Society 
member, is open to all and it is free. 
Any Computer Society member can 
join as many as four TCs, receive their 
newsletters, receive discounts on TC- 
sponsored events, and benefit from 
many other TC activities simply by 
filling out and sending in an applica¬ 
tion form. 

The strategic plan adopted by the 
society’s Board of Governors last year 
gave our TCs greater opportunities to 
grow, along with more fiscal responsi¬ 
bility. The year 1992 will be one of 
great change within TAB. TAB now 
has a mechanism whereby each TC 
gets to keep a portion of the surplus 
from any workshop or conference it 
initiates. The result, for successful 
TCs, will be an increase in the funds 


available to implement new programs 
in its area — for the direct benefit of 
its members. 

To keep up with constantly chang¬ 
ing technology, our TCs must change. 
Not only do the scope and goals of a 
TC change over time, but new TCs are 
created and TCs that become obsolete 
are eliminated. We are constantly 
looking for new areas in which the so¬ 
ciety should participate. Ad hoc task 
forces are frequently formed to study 
new subjects, often leading to the for¬ 
mation of a TC. Currently, we have 
task forces in parallel processing and 
computer-based systems engineering. 
A task force in multimedia computing 
is in its infancy. Work is under way to 
establish task forces in computational 
science and information systems. 

While our technical activities pro¬ 
gram is exciting, it is not perfect. We 
have some TCs that exist in name 
only. Others have only a minimal set 
of activities. Worse yet, there are ar¬ 
eas in which we should be active but 
are not. Why? Because it takes volun¬ 
teers to organize a conference or 
workshop, edit a newsletter, give a tu¬ 
torial, attend a lecture, or help with 
ballots. What we need is you. TAB is 
composed of individuals who believe 
they get even more from their mem¬ 
bership when they actively participate 
in TCs and thereby serve not only the 
society, but the profession as well. For 
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them, just being a member of the soci¬ 
ety is not enough. 

Computer Society members receive 
a great deal of value for their mem¬ 
bership. Working as volunteers is a 
way for us to give something back. 
Doing so requires a little bit of our 
time, perhaps a few hours each week, 


IEEE Computer Society 

Technical committees in the Com¬ 
puter Society are networks of profes¬ 
sionals with common interests in com¬ 
puter hardware, software, appli¬ 
cations, and interdisciplinary fields. 
TCs directly influence society stan¬ 
dards, publications, conferences, 
workshops, education, and chapter ac¬ 
tivities. Activities are planned and co¬ 
ordinated by the Technical Activities 
Board and the Technical Activities 
Board Operating Committee. 

Through task forces, TAB plans for 
the society’s future technical focus. 
Technical committee activities typi¬ 
cally include organizing workshops, 
symposia, and technical sessions at 
major Computer Society conferences. 
Many TCs also publish newsletters. 
Members are invited to join one or 
more of the 32 active Computer Soci¬ 
ety technical committees, or propose 
new committees in different interest 
areas. For more information, contact 
IEEE Computer Society Headquar¬ 
ters, 1730 Massachusetts Ave. NW, 
Washington, DC 20036-1903, phone 
(202) 371-0101. 

Hardware 

The Computer Architecture TC is in¬ 
volved with research and develop¬ 
ment in the integrated hardware and 
software design of general- and spe¬ 
cial-purpose digital computers. The 
TC annually cosponsors, with ACM 
SIGArch, the international Sympo¬ 
sium on Computer Architecture, and 
often conducts workshops in such ar¬ 
eas as computer arithmetic and inter¬ 
connection networks. With SIGArch, 
it administers the Eckert-Mauchly 
Award for contributions to computer 
architecture. It also helps organize 
special issues of society periodicals 
and publishes a quarterly newsletter 
containing meeting reports, calls for 
papers, and news announcements. 
Chair: Roger Anderson, 4354 Gulford 
Ave., Livermore, CA 94550, Comp- 
mail rog.anderson. 


but we believe it is rewarding and 
fun. 

There’s the challenge. It is straight¬ 
forward. We encourage you to be¬ 
come active in one or more TCs. It 
will benefit you, your society, and 
your profession. Joining a TC is the 
first step. Volunteering to help is the 


technical committees 

The Computer Elements TC is con¬ 
cerned with circuits, memories, I/O 
devices and systems, and their interre¬ 
lationships. This includes such factors 
as performance, testing, micropro¬ 
gramming, software, and packaging as 
they relate to computer elements. 
VLSI technology and its system impli¬ 
cations are of particular interest. The 
TC sponsors two annual workshops 
and one biennial workshop, and pro¬ 
vides sessions for Compcon. Chair: 
Bhadrik Dalai, Amdahl Corp., MS 
324,1250 E. Arques Ave., PO Box 
3474, Sunnyvale, CA 94088-3470, 
phone (408) 746-8203, Compmail 
b.dalal. 

The Computer Packaging TC deals 
with the physical design problems of 
building computers and similar large- 
circuit assemblies. The TC runs eight 
one-day technical meetings and spon¬ 
sors a three-day packaging workshop 
each year. These meetings address 
such topics as chip packages, ceramic 
or reinforced plastic circuit boards 
and connectors, interconnection, ca¬ 
bling and related cabinet power sup¬ 
ply, and heat-removal hardware. 

Chair: Lorna Capodanno, AT&T Bell 
Laboratories, 1247 S. Cedar Crest 
Blvd., Allentown, PA 18103, phone 
(215) 770-2187, e-mail lori@alux2. 
att.com. 

The Microprocessors and Microcom¬ 
puters TC is involved with the archi¬ 
tecture, design, and application of mi¬ 
croprocessors and microcomputers. 
The TC sponsors and facilitates tech¬ 
nical activities across the disciplines of 
computer architectures, programming 
languages, and operating systems. It 
cosponsors the ASPLOS (Architectur¬ 
al Support for Programming Languag¬ 
es and Operating Systems) Confer¬ 
ence, is active in the standards area 
through its Microprocessor and Mi¬ 
crocomputer Standards Committee, 
and publishes a newsletter. Chair: 
Hasan Alkhatib, Dept, of Computer 
Engineering, Santa Clara University, 


second step, and the one that will 
make a difference. 

Joseph Boykin 

Vice President, Technical Activities 

Bruce D. Shriver 
President 


Santa Clara, CA 95153, phone (408) 
554-4485, e-mail halkhatib%scu. 
bitnet@bitnet.cc.cmu.edu. 

The Microprogramming and Microar¬ 
chitecture TC addresses all aspects of 
microprogramming and its support 
tools, giving particular attention to 
microprogramming languages, archi¬ 
tectures of microprogrammable ma¬ 
chines, emulation, simulators, control 
storage technologies, microprogram 
design tools, and applications of mi¬ 
croprogramming. The TC sponsors 
workshops, tutorials publications, and 
conferences. In conjunction with SIG- 
Micro, the TC publishes a quarterly 
newsletter. Chair: Yashwant Malaiya, 
Computer Science Dept., Colorado 
State University, Fort Collins, CO 
80523, phone (303) 491-7031, e-mail 
malaiya@cs.colostate.edu. 

The Multiple-Valued Logic TC pro¬ 
motes research in the theory and ap¬ 
plication of many-valued systems. Its 
scope includes devices, VLSI, circuit 
design techniques, fault tolerance, 
probabilistic/continuous-valued sys¬ 
tems, and philosophic/algebraic con¬ 
siderations. The TC sponsors a sym¬ 
posium each May and cosponsors the 
International Conference on Archi¬ 
tectural Support for Programming 
Languages. Other activities include 
organizing sessions at large conferenc¬ 
es, planning workshops, and publica¬ 
tion of a newsletter. Chair: K.W. Cur¬ 
rent, EECS Dept., University of 
California at Davis, Davis, CA 95616, 
phone (916) 752-1839, e-mail 
current@iris.ucdavis.edu. 

The Test Technology TC considers all 
aspects of system, board, and device 
testing with design, manufacturing, 
and field considerations in mind. Top¬ 
ics of interest include design for test¬ 
ability, built-in self-test, DSP testing 
techniques, memory test, and test 
hardware and software. Special em¬ 
phasis is given to LSI and VLSI devic¬ 
es. The TC supports the technical con- 
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tent of IEEE Design & Test magazine, 
publications of the Computer Society 
Press, and a comprehensive leading- 
edge tutorial program. It cosponsors 
the IEEE International Test Confer¬ 
ence (ITC), and sponsors four work¬ 
shops: the Built-In Self-Test Work¬ 
shop, the Design for Testability 
Workshop, and the VLSI Workshop. 
The TC publishes a quarterly newslet¬ 
ter in IEEE Design & Test. Chair: 
Daniel Graham, InTest Corp., 12 
Springdale Rd., Cherry Hill, NJ 
08003, phone (609) 424-6886. 

The VLSI TC addresses the interac¬ 
tion between the semiconductor pro¬ 
cess and system design on VLSI. Em¬ 
phasis falls on integrating the design, 
fabrication, application, and business 
aspects of VLSI from both hardware 
and software points of view. The TC 
sponsors conferences, special sessions, 
and workshops for the Computer So¬ 
ciety. Chair: Pasupathi Subrahmany- 
am, Bell Labs, Rm. 4E-530, AT&T 
Bell Labs, Holmdel, NJ 07733, phone 
(908) 949-5812, e-mail subra@vaxl35. 
att.com. 


Software 

The Computer Languages TC extends 
its interest beyond conventional high- 
level programming languages to in¬ 
clude all the computer-related lan¬ 
guages such as requirements, 
specification, design, test, and query 
languages. The TC sponsors the Com¬ 
puter Language Conference, the Ada 
Applications and Environment Con¬ 
ference, the Symposium on Logic Pro¬ 
gramming, and other workshops on 
language-related issues. Through 
committees within the TC, individual 
languages and special topics receive 
detailed coverage. A quarterly news¬ 
letter reports current items of profes¬ 
sional interest. Chair: Forouzan Gol- 
shani. Dept, of Computer Science, 
Arizona State University, Tempe, AZ 
85287, phone (602) 965-2855. 

The Data Engineering TC is con¬ 
cerned with the role of data in the de¬ 
sign, development, management, and 
utilization of information systems. Is¬ 
sues of interest include database de¬ 
sign; knowledge of the data and its 
processing; languages to describe 
data, define access, and manipulate 
databases; strategies and mechanisms 
for data access, security, and integrity 
control; and engineering services and 
distributed systems. The TC sponsors 
the Data Engineering Conference and 
cosponsors the international Confer¬ 


ence on Very Large.Databases. It is 
involved with other conferences, sym¬ 
posia, and workshops, and publishes a 
quarterly newsletter. 

The Operating Systems and Applica¬ 
tion Environments TC is involved 
with theoretical and practical aspects 
of operating system design, including 
system organization, resource alloca¬ 
tion policies, measurement, perfor¬ 
mance evaluation, and system reliabil¬ 
ity. The TC publishes a newsletter 
four times a year. Chair: Jehan-Fran- 
cois Paris, Dept, of Computer Science, 
University of Houston, Houston, TX 
77204-3475, phone (713) 749-3943, 
e-mail paris@cs.uh.edu. 

The Real-Time Systems TC addresses 
hardware and software issues related 
to the use of computers in real-time 
data systems, operating systems, pro¬ 
cessing of acquired data, database 
management, process control, data ac¬ 
quisition networks, industrial systems, 
and data communications in both dis¬ 
tributed- and parallel-computing envi¬ 
ronments. It organizes and sponsors 
the Real-Time Systems Symposium 
and other workshops on real-time sys¬ 
tems. The TC publishes a quarterly 
newsletter. Chair: Kang G. Shin, 
Real-Time Computing Laboratory, 
Dept, of Electrical Engineering and 
Computer Science, University of 
Michigan, Ann Arbor, MI 48109-2122, 
phone (313) 763-0391, e-mail kgshin@ 
eecs.umich.edu. * 

The Security and Privacy TC is in¬ 
volved with operating system security, 
data encryption, access control mech¬ 
anisms, database protection, network 
security, and other aspects of protec¬ 
tion in computer systems. It addresses 
such issues as privacy protection legis¬ 
lation and its technological impact. It 
participates in developing standards in 
data security and publishes a quarter¬ 
ly newsletter. Cipher, four times a 
year. It sponsors the annual Sympo¬ 
sium on Security and Privacy. Chair: 
John McHugh, Dept, of Computer 
Science, Sitterson Hall CB 3175, Uni¬ 
versity of North Carolina, Chapel 
Hill, NC 27599-3175, phone (919) 962- 
1826, e-mail mchugh@cs.unc.edu. 

The Software Engineering TC encour¬ 
ages the application of engineering 
methods and principles to the devel¬ 
opment of computer software and 
works to increase professional knowl¬ 
edge of techniques, tools, and empiri¬ 
cal data to improve software quality. 
The TC cosponsors conferences, in¬ 
cluding the International Conference 


on Software Engineering, and several 
informal workshops every year. A TC 
subcommittee develops proposals for 
IEEE software engineering standards. 
A quarterly newsletter, Software En¬ 
gineering, informs members of current 
events and technical results. Chair: 
Anneliese von Mayrhauser, Colorado 
State University, Dept, of Computer 
Science, 601 Howes Ln., Rm. 239, 

Fort Collins, CO 80523, phone (303) 
491-7016, e-mail avm@handel.cs. 
colostate.edu. 

Applications 

The Computational Medicine TC is 

dedicated to research in computer sci¬ 
ence and engineering as it applies to 
medicine and health services, and to 
facilitating communication between 
system designers and users. The TC 
encourages innovation and emphasiz¬ 
es developments on computer applica¬ 
tions in medicine. It cosponsors sym¬ 
posia, organizes and sponsors 
workshops and tutorials, and contrib¬ 
utes to scientific/technical publica¬ 
tions. The TC conducts education and 
standards development, information 
distribution, and student activities, or¬ 
ganizes special-interest groups, and 
publishes a newsletter. Chair: Marga¬ 
ret Peterson, Dept, of Biomechanics, 
Hospital for Special Surgery, 535 E. 
70th St., New York, NY 10021, phone 
(212) 606-1424. 

The Computer Communications TC 

promotes activities, disseminates in¬ 
formation, and furthers the growth of 
those systems that integrate comput¬ 
ing functions and telecommunications 
facilities. The TC sponsors the “802” 
series of local and metropolitan area 
networks standards. It also annually 
sponsors the society’s Conference on 
Local Computer Networks and the 
Computer Networking Symposium. In 
addition, it is a sponsor of the biennial 
Data Communications Symposium. 
Chair: Ken Thurber, Architecture 
Technology Corp., PO Box 24344, 
Minneapolis, MN 55424-0344, phone 
(612) 935-2035. 

The Computer Graphics TC promotes 
research in computer graphics and the 
application of graphics to science, en¬ 
gineering, business, and the arts. Re¬ 
search interests include hardware, 
software, algorithms, and user inter¬ 
faces, as well as education and stan¬ 
dards. The TC sponsors conferences 
and workshops and contributes to 
publications. Its newsletter, Computer 
Graphics Bulletin, is published twice a 
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CASE Was Never This Easy Before 

MacAnalyst and MacDesigner 



Structured Analysis 
Real-Time Analysis 
Data Modeling 
Object-Oriented Analysis 
Structured Design 
Data Dictionary 
Requirement Database 
Screen Prototyping 

With schedules tight you’ll appreciate 
a CASE tool with all the capabilities you 
need, for even the most demanding project. 
That works just as you’d expect. Like 
your other Macintosh productivity tools. 


With the time you save by not having 
to learn a new way of doing things, you’ll 
boost productivity as well as quality. 

You’ll also be in good company when 
you join the ranks of hundreds like Boe¬ 
ing, Dupont, Motorola, and Visa Corpora¬ 
tion who have made MacAnalyst and 
MacDesigner the standard in Macintosh 
CASE tools. 

Perhaps best of all, its easy to justify 
the hardware and software investment re¬ 
quired to bring out the very best in your 
development team. 

Excel Software 


P.O. Box 1414 • Marshalltown, IA 50158 • Phone: 515-752-5359 • Fax: 515-752-2435 
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year and includes topics spanning 
computer graphics and applications. 
Chair: Arie Kaufman, Dept, of Com¬ 
puter Science, State University of 
New York, Stony Brook, NY 11790, 
phone (516) 632-8441, e-mail ari@ 
cs.sunysb.edu. 

The Expert Systems Applications TC 

is dedicated to improving the ability 
of organizations and individuals to 
work with expert systems technolo¬ 
gies. Expert systems are the most ma¬ 
ture and resilient products to emerge 
from the AI community, and they are 
being adopted by corporations and 
government organizations to improve 
productivity. The objectives of this TC 
include injecting “how-to” skills into 
formal education programs, imple¬ 
menting industry standards to support 
the field, and identifying synergisms 
across technological and organization¬ 
al boundaries. The TC develops and 
participates in educational programs, 
technical meetings, and publications. 
Chair: Harry Siegel, VSI, 1350 Bever¬ 
ly Rd„ Suite 115-254, McLean, VA 
22101, phone (703) 442-7925, Comp- 
mail h.siegel. 

The Oceanic Engineering and Tech¬ 
nology TC is involved with the appli¬ 
cation of computers and computer 
technology to ocean-related matters, 
including microprocessor applications 
in marine environments. Through the 
IEEE Oceanic Engineering Council, 
the TC supports the Offshore Techni¬ 
cal Conference and the IEEE Oceans 
Conference. It sponsors various work¬ 
shops and tutorials, and publishes a 
newsletter twice a year. Chair: 
Michael Guberek, Global Imaging, 

201 Lomas Santa Fe Dr., Suite 360, 
Solana Beach, CA 92075, phone (619) 
481-5750. 

The Office Automation TC considers 
all aspects of computer technologies 
used to support and automate office 
activities. The scope covers office sys¬ 
tems, applications, connections, and 
configurations. All facets of the han¬ 
dling and processing of office equip¬ 
ment are of interest. Technical areas 
range from model, requirement, archi¬ 
tecture, interface, language, integra¬ 
tion, and control to social and human 
factors. The TC sponsors workshops 
and conferences and cosponsors the 
ACM/IEEE Conference on Office In¬ 
formation Systems. It publishes a 
newsletter, Office Knowledge Engi¬ 
neering, four times a year. Chair: Fre¬ 
derick H. Lochovsky, Dept, of Com¬ 
puter Science, Hong Kong University 
of Science and Technology, 5/F World 


Shipping Center, 7 Canton Rd., Hong 
Kong, phone 852 302-1642, e-mail 
csfred@usthk.bitnet. 

The Pattern Analysis and Machine in¬ 
telligence TC is concerned with pat¬ 
tern recognition, artificial intelligence, 
expert systems, natural-language un¬ 
derstanding, image processing, and 
computer vision. Its interests include 
methodology, applications, systems 
organization, and technology. The TC 
sponsors the Computer Vision and 
Pattern Recognition Conference and 
the Artificial Intelligence Applica¬ 
tions Conference, as well as the 
Workshop on Computer Architecture 
for Pattern and Machine Intelligence, 
the Conference on Applied Imagery 
Pattern Recognition, and the Work¬ 
shop on Computer Vision. The TC 
also publishes a newsletter. Chair: Avi 
Kak, School of Electrical Engineering, 
Purdue University, West Lafayette, 

IN 47907-1285, phone (317) 494-3551, 
e-mail kak@ecn.purdue.edu. 

The Robotics TC considers robot con¬ 
trol systems, robot programming lan¬ 
guages, planning and spatial reason¬ 
ing, interpretation of sensor signals, 
application of machine vision to robot 
control, and the interaction of robot¬ 
ics with CAD/CAM functions. The 
technical focus is directed more to¬ 
ward the control and machine percep¬ 
tion aspects of the field than manipu¬ 
lator mechanics and detailed 
applications. The TC publishes a 
newsletter twice a year. Chair: 

Ramesh Jain, University of Michigan, 
AI Lab., 1101 Beal Ave., Ann Arbor, 
MI 48109, phone (313) 764-8505, 
e-mailjain@caen.engin.umich.edu. 

The Simulation TC promotes all as¬ 
pects of research, development, meth¬ 
odologies, and applications of mathe¬ 
matical modeling, and analog and 
digital computer simulation. The TC 
organizes technical sessions at Com¬ 
puter Society conferences and cospon¬ 
sors the annual Symposium on the 
Simulation of Computer Networks 
and the Winter Simulation Confer¬ 
ence. It publishes a newsletter, which 
includes technical papers, tutorials on 
modeling and simulation, book re¬ 
views, and abstracts of current re¬ 
search. Chair: Adel Elmaghraby, Uni¬ 
versity of Louisville, EMACS Dept., 
Speed Scientific School, Louisville, 

KY 40292, phone (502) 588-6305, 
e-mail aselma01@ulkyvx.bitnet. 

The Supercomputing Applications TC 

focuses on the relationship of scientif¬ 
ic and mathematic disciplines and 


their implementation on supercom¬ 
puters. This includes algorithms and 
architectures, large-memory hierar¬ 
chies, and conversion of ideas to soft¬ 
ware. The TC publishes a quarterly 
newsletter and plans to cosponsor 
workshops and conferences. Chair: 
Alfred E. Brenner, Supercomputing 
Research Center, 17100 Science Dr., 
Bowie, MD 20715, phone (301) 805- 
7400, e-mail brenner@super.org. 

Interdisciplinary 

The Computers in Education TC con¬ 
siders the technical aspects of evaluat¬ 
ing, specifying, designing, and imple¬ 
menting hardware and software 
forming educational computing sys¬ 
tems. The TC analyzes the use of 
computers in preschool through post¬ 
college education. Specific topics in¬ 
clude hardware/software standards; 
design and implementation of produc¬ 
tion systems; specification and design 
of educational computer systems; and 
analysis specification, design, and im¬ 
plementation of effective hardware 
learning systems for microcomputer 
laboratories at all levels. The commit¬ 
tee sponsors workshops, tutorials, and 
conferences, and acts as a resource to 
the society’s Educational Activities 
Board for the development of curricu¬ 
la and other educational policy. The 
TC publishes a newsletter four times a 
year. 

The Computing and Persons with Dis¬ 
abilities TC promotes the use of mod¬ 
ern computer technology in the reha¬ 
bilitation, education, and employment 
of handicapped persons. The TC en¬ 
courages interchange among scien¬ 
tists, engineers, clinicians, and the 
handicapped community. It sponsors 
workshops, symposia, tutorials, and 
special sessions at conferences. Chair: 
James Caldwell, IBM, Sys. Adv. Man¬ 
ufacturing Eng., Dept. 16T, Bldg. 45, 
Rm. 3cl27, Austin, TX 78758, phone 
(512) 838-6053, e-mail caldwell@ 
ausvmr.vnet.ibm.com. 

The Design Automation TC is in¬ 
volved with the use of computer-ori¬ 
ented techniques in all aspects of the 
design process, with particular empha¬ 
sis on design languages, logic synthe¬ 
sis, verification techniques (including 
digital simulation), manufacturing in¬ 
terface data, graphics, and database 
management. The TC sponsors the 
Workshop on High-Level Synthesis; 
cosponsors, with ACM SIGDA, the 
annual ACM/IEEE Design Automa¬ 
tion Conference; and publishes the 
Design Automation TC Newsletter 
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From the analytical engine to the 
supercomputer, from Pascal to Von 
Neumann, from punched cards to CD- 
ROMs — the IEEE ANNALS OF THE 
HISTORY OF COMPUTING covers the 
breadth of computer history. Featuring 
scholarly articles by leading computer 
scientists and historians, as well as first¬ 
hand accounts by computer pioneers, the 
ANNALS is the primary publication for 
recording, analyzing, and debating the 
history of computing. 

The ANNALS also serves as a focal point 
for people who are interested in uncovering 
and preserving the records of this exciting 
field. The quarterly publication is an active 
center for the collection and dissemination 
of information on historical projects and 
organizations, oral history activities, and 
international conferences. Regular depart¬ 
ments include Happenings; Anecdotes; 
Biographies; Comments, Queries, and 
Debate; and Reviews. 

The ANNALS (formerly published by 
AFIPS and Springer-Verlag) will go into its 
14th year of publication in 1992 under the 
auspices of the IEEE Computer Society. 
Special issues on Time-Sharing and 
Interactive Computing at MIT, the 
University of Cambridge Computation 
Laboratory, and the Resurrection and 
Reconstuction of Notable Machines are 
now in preparation. 


Mail or fax to appropriate Computer Society office: 

EUROPE: 13, Avenue de I’Aquilon, B-1200, Brussels, BELGIUM. Fax: 32-2-770-8505 

PACIFIC RIM: Ooshima Building, 2-19-1 Minami-Aoyama, Minato-ku, Tokyo 107, JAPAN. Fax: 81-3-3408-3553 

ALL OTHERS: 10662 Los Vaqueros Circle, PO Box 3014, Los Alamitos, CA 90720-1264 USA. Fax: 714-821-4010 

























four times a year in IEEE Design & 
Test magazine. Chair: Joanne De- 
Groat, Ohio State University, 205 
Dreese Lab, 2015 Neil Ave., Colum¬ 
bus, OH 43210-1272, phone (614) 292- 
2439, Compmail j.degroat. 

The Distributed Processing TC ad¬ 
dresses the technical aspects of speci¬ 
fying, designing, implementing, and 
evaluating distributed-computing sys¬ 
tems. Specific topics of interest in¬ 
clude executive and operating systems 
for decentralized control, logical and 
physical interconnection and commu¬ 
nication, reliability and fault toler¬ 
ance, systems and hardware architec¬ 
ture, distributed databases, and 
software specification, verification, 
applications, and systems. The TC 
sponsors workshops and conference 
sessions on these and related topics, 
as well as the annual International 
Conference on Distributed-Comput¬ 
ing Systems, along with the annual 
Symposium on Reliability in Distrib¬ 
uted Software and Database Systems. 
Chair: Bill Buckles, Dept, of Comput¬ 
er Science, Tulane University, New 
Orleans, LA 70118, phone (504) 865- 
5840, e-mail buckles@cs.tulane.edu. 

The Fault-Tolerant-Computing TC is 

concerned with the design, analysis, 
testing, verification, and evaluation of 
systems subject to faults that occur 
during design or use. Technical activi¬ 


ty in these areas ranges from basic re¬ 
search to current fault-tolerant-design 
practice and field experience. The TC 
cosponsors the annual International 
Symposium on Fault-Tolerant Com¬ 
puting and sponsors the Workshop on 
Fault Tolerance in Parallel and Dis¬ 
tributed Computing. Chair: Jacob 
Abraham, Dept, of Electrical and 
Computer Eng., Engineering Science 
Bldg., University of Texas at Austin, 
Austin, TX 78712, phone (512) 471- 
8983, e-mail jaa@ece.utexas.edu. 

The Mass Storage Systems and Tech¬ 
nology TC is involved with the organi¬ 
zation, storage and retrieval, and 
hardware requirements of large data 
collections. Unconventional data col¬ 
lections and processing systems are 
considered in addition to the conven¬ 
tional types, including special-purpose 
CPUs, mass storage devices, operating 
systems, and languages. The TC offers 
tutorials and workshops each year on 
these and other current topics. Chair: 
Sam Coleman, Lawrence Livermore 
National Laboratory, MS L-60, PO 
Box 808, 7000 East Ave., Livermore, 
CA 94550, phone (510) 422-4323, 
e-mail scoleman@llnl.gov. 

The Mathematical Foundations of 
Computing TC is interested in the 
mathematics underlying the power, 
complexity, and design of computing 
devices, algorithms, and programs. It 


sponsors the annual Symposium on 
Foundations of Computer Science, 
which presents original research on 
such topics as automata and formal 
languages, computational complexity, 
data structures, formal semantics, 
mathematics of computation, mathe¬ 
matical studies of computer systems, 
and algorithm theory. Chair: Manuel 
Blum, University of California at Ber¬ 
keley, Dept, of Computer Science, 
Berkeley, CA 94720, phone (415) 642- 
1662, e-mail blum@berkeley.arpa.edu. 

The Personal Computing TC is dedi¬ 
cated to encouraging the development 
and application of personal computer 
technology in industry, business, and 
education. It holds workshops such as 
the Personal Computing Workshop, 
giving special emphasis to personal 
computer technology, software, and 
courseware. It provides a forum for 
interaction among educators, indus¬ 
try, and the user community. The TC 
encourages article submissions to 
Computer and IEEE Micro and spon¬ 
sors user tutorials. It also plays an ac¬ 
tive role in personal computer activi¬ 
ties and sessions at the major 
Computer Society conferences. The 
TC’s newsletter is published four 
times a year. Chair: Stephen Ruth, 
Dept, of Decision Sciences, George 
Mason University, 4400 University 
Dr., Fairfax, VA 22030, phone (703) 
993-1789, e-mail ruth@gmuvax. 


“Authentication” revisited 


T.Y.C. Woo and S.S. Lam, University of Texas at Austin 


In our article published in the Janu¬ 
ary 1992 issue of Computer,' the peer- 
peer authentication protocol shown in 
Figure 5 on page 47 needs augmenta¬ 
tion. The protocol should read 

(1) P A: P,Q 

(2) A —> P: [Q,k Q ) k , 

(3) P ^>Q: \n P ,P} kQ 

(4) Q -> A: Q, P, [n P } kA 

(5) A ->Q: \P, k P } k ,, 

{{n P , k, P, Q] k -i} ka 

(6) Q P: {\n P , k, P, Q} k . u n Q j tp 

(7) P ^Q: {n Q ) k 

Note that the letter P preceding the 
letter Q in steps (5) and (6) is missing 
in the previously published version. 
(We inadvertently submitted an old 


version of the figure to Computer, for 
which we apologize.) 

As we analyzed the protocol in Fig¬ 
ure 5, we also found a way to reduce 
the number of protocol steps for peer- 
peer authentication from seven to 
five: 


(1) P -> Q'- 

P, n P 

(2) Q -» A: 

P, Q, n Q 

(3) A -> Q: 

[P, Utf . 


{[n P , ri Q , P, Q, k], 

(4) Q -> P: 

\\n P ,n Q ,P, Q, k) k 

(5) P -> Q: 

[n Q ) k 


Aside from being more efficient, 
this protocol is also interesting in that 
it can be viewed as an extension of the 
well-known three-way handshake pro¬ 
tocol for establishing connections. 2 In 


particular, steps (1), (4), and (5) cor¬ 
respond to steps of the basic three- 
way handshake. But, in addition to es¬ 
tablishing a new connection, the 
five-step protocol achieves mutual au¬ 
thentication. 
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The Usability 
Engineering 
Life Cycle 


Jakob Nielsen, Bellcore 


■■■■■I 

A usability engineering 
process to ensure good 
user interfaces includes 
elements to be 
considered before the 
design, during the 
design, and after field 
installation of a 
software product. 


C omputer user interfaces have become more important with the increase 
in number of users and applications. The personal-computer revolution 
and falling hardware prices made computers available to ever broader 
groups of people who use computers for a larger variety of tasks. Initially, when 
computers were used by only a few people performing specialized tasks, it made 
some sense to require a high degree of user expertise. Also, because computers 
were so expensive, it was not unreasonable to let users suffer a little in favor of 
computational efficiency. Now, however, it pays to dedicate a large portion of 
computational resources — CPU cycles, memory use, communication bandwidth, 
screen space, and development effort — exclusively to making life easier for the 
user. 

Users are becoming less willing to put up with difficult or uncomfortable 
interfaces since experience with some current interfaces has shown them that 
software can indeed be easy to learn and pleasant to use. In an unpublished study 
from 1990, Tim Frank Andersen of the Technical University of Denmark read 70 
reviews of software products in various personal computer magazines and counted 
784 comments on the usability of the reviewed software. This is an average of 11.2 
usability comments per software review. Many of these comments were fairly 
superficial, but their sheer number indicates the importance of usability to today’s 
users. 

High usability is thus desirable, but it does not magically appear just because we 
want it. To ensure the usability of interactive computer products, we must actively 
include usability concerns in the software development process. Of course, nobody 
deliberately sets out to design an unusable interface, but only a systematic usability 
effort using established methods can qualify as usability engineering. Good inten¬ 
tions are not enough. 

This article presents a practical usability engineering process that can easily be 
incorporated into the product development process as steps to be taken in roughly 
chronological order. Because the article considers the life cycle, several of the 
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steps are iterative and some may over¬ 
lap. The actions needed to ensure us¬ 
ability form the usability process. The 
model presented should therefore be 
seen as advice about what to include in 
the design and implementation process. 
In this context, I am not giving advice 
about the properties of the product of 
this process. Many such guidelines ex¬ 
ist, and studying and applying selected 
guidelines is one of the recommended 

Usability engineering 
model 

The model presented here is a modi¬ 
fied and extended version of Gould and 
Lewis’ “golden rules”: early focus on 
users, user participation in the design, 
coordination of the different parts of 
the user interface, empirical user test¬ 
ing, and iterative revision of designs 
based on the test results. 1 Further inspi¬ 
ration and modifications came from work 
on usability engineering. 2,3 

Figure 1 lists the elements in the com¬ 
plete usability engineering model. How¬ 
ever, the effort can be successful with¬ 
out including every refinement. (See 
the final section of this article for a 
prioritization of methods under varying 
levels of resource constraints.) 

The most basic elements in the us¬ 
ability engineering model are empirical 
user testing and prototyping, combined 
with iterative design. Because it’s near¬ 
ly impossible to design a user interface 
right the first time, we need to test, 
prototype, and plan for modification by 
using iterative design. Under typical 
resource constraints, modifications will 
be feasible only in the prototyping stage. 
It is much too expensive to change a 
completely implemented product, es¬ 
pecially if testing reveals the need for 
fundamental changes in the interface 
structure. 

Product development 
context 

The following sections present usabil¬ 
ity activities for three main phases of a 
software project: before, during, and 
after product design and implementa¬ 
tion. The constraints of the print medi¬ 
um necessitate a sequential presenta- 


0. Consider the larger context 

1. Know the user 

Individual user characteristics 
The user’s current task 
Functional analysis 
Evolution of the user 

2. Competitive analysis 

3. Setting usability goals 

4. Participatory design 

5. Coordinated design of the total interface 

Standards 
Product identity 

6. Guidelines and heuristic analysis 

7. Prototyping 

8. Empirical testing 

9. Iterative design 

Capture the design rationale 
10. Collect feedback from field use 


Apply 

metamethods 

throughout 

Prioritize the 
usability methods 


Figure 1. Elements of the usability engineering model. 


tion of these usability activities, even 
though they should really be applied 
iteratively in the manner of Boehm’s 
spiral model of the software process. 4 

Software development and user in¬ 
terface design are both part of a broad¬ 
er corporate product-development con¬ 
text in which one-shot projects are fairly 
rare. Usability should apply to the de¬ 
velopment of entire product families 
and extended projects where products 
are released in several versions over 
time. 

This broader context strengthens the 
arguments for allocating substantial us¬ 
ability engineering resources as early as 
possible. Design decisions made for early 
products have ripple effects because 
subsequent products and versions must 
be backward compatible. Consequent¬ 
ly, some usability engineering special¬ 
ists believe that “human factors involve¬ 
ment with a particular product may 
ultimately have its greatest impact on 
future product releases.” 5 Of course, 
having to plan for future versions is also 
a compelling reason to follow the initial 
product release with field studies of its 
actual use. 

The term life cycle is normally de¬ 
fined (IEEE standard 100-1988) as start¬ 
ing when a software product is con¬ 
ceived and ending when the product is 
no longer available for use. The usabil¬ 
ity engineering life cycle extends be¬ 
yond this period because of the impact 


of usability decisions on future prod¬ 
ucts and their life cycles. We must con¬ 
sider not just how an interface design 
meets current needs but also whether it 
conflicts with skills users have acquired 
from previous interfaces and whether it 
seems flexible enough to be extended 
for future interfaces. 

Predesign stage 

The first stage of the usability life 
cycle aims at understanding the target 
user population and user tasks. We can 
make valid design decisions and appro¬ 
priate trade-offs only when we under¬ 
stand these factors, so gathering this 
information should be the first priority. 

We should not rush into design. The 
least expensive way for usability activi¬ 
ties to influence a product is to do as 
much as possible before design is start¬ 
ed. Then it will not be necessary to 
change the design to comply with the 
usability recommendations, and it may 
be possible to avoid developing unnec¬ 
essary features. 

Several of the predesign usability ac¬ 
tivities might be considered part of a 
market research or product planning 
process and be performed by marketing 
groups. However, traditional market 
research does not use all the needed 
usability design methods, and the re¬ 
sults are often poorly communicated to 


March 1992 








developers. But there should be no need 
for duplicate efforts if management suc¬ 
cessfully integrates usability and mar¬ 
keting activities. An outcome of such 
integration could be the consideration 
of product usability attributes as fea¬ 
tures to be used by marketing to differ¬ 
entiate the product. 

Know the user. The first step in the 
usability process is to study the prod¬ 
uct’s intended users. As a minimum, 
developers should visit a customer site 
to gain a feel for how the product will be 
used. Individual user differences and 
variability in tasks are the two factors 
with the largest impact on usability, so 
they need to be studied carefully. De¬ 
velopers should also keep in mind that 
users often include installers, maintain¬ 
ed, system administrators, and other 
support staff, in addition to the people 
who sit at the keyboard. The concept of 
“user” should be defined to include ev¬ 
eryone whose work is affected by the 
product. 

Individual user characteristics. We 
should know the type of people who will 
be using the system. In some situations 
it’s possible to identify the users as spe¬ 
cific individuals — for example, when 
the product is going to be used in a 
specific department in a particular com¬ 
pany. For products with more widely 
scattered users, it’s possible to visit only 
a few, representative customers. Alter¬ 
natively, the products might be aimed 
toward the entire population or a very 
large subset. 

By knowing the users’ work experi¬ 
ence, educational level, age, previous 
computer experience, and so on, we can 
anticipate their learning difficulties to 
some extent and better set appropriate 
limits for user interface complexity. 
Certainly, we also need to know the 
users’ reading and language skills. For 
example, very young children with no 
reading ability require a nontextual in¬ 
terface. 

The users’ work environment and 
social context are also important. As a 
simple example, the use of audible 
alarms, “beeps,” or more elaborate 
sound effects may not be appropriate 
for users in open office environments. 
In a field interview I conducted, a secre¬ 
tary insisted on the ability to shut off the 
beep; she feared that others would think 
she was stupid if her computer beeped 
at her all the time. 


User differences and 
task variability are the 
two factors with the 
largest impact on usability. 
Study them carefully. 


A great deal of the information need¬ 
ed to characterize individual users may 
come from market analysis or as a side 
benefit of observational studies con¬ 
ducted for task analysis. We can also 
collect such information directly through 
questionnaires or interviews. In any case, 
it’s best not to rely totally on written 
information. New insights are almost 
always achieved by observing actual 
users in their own working environments. 

The user’s current task. A task analy¬ 
sis is extremely important as early input 
to the system design. The users’ overall 
goals should be studied, as well as how 
they currently approach the task, what 
their information needs are, and how 
they deal with exceptional circumstanc¬ 
es or emergencies. For example, sys¬ 
tematic observation of users talking to 
their clients may reveal input and out¬ 
put needs for a transactions processing 
system. The users’ model of the task 
should also be identified, because it can 
be used as a source for metaphors for 
the user interface. Also, we should seek 
out and observe especially effective us¬ 
ers and user strategies and “work 
arounds” as hints of what a new system 
could support. Finally, we should try to 
identify the weaknesses of the current 
situation: points where users fail to 
achieve goals, spend excessive time, or 
are made uncomfortable. These weak¬ 
nesses present opportunities for prod¬ 
uct improvements. 

Functional analysis. A new computer 
system should not propagate subopti- 
mal methods that may have been insti¬ 
tuted because of limitations in previous 
technologies. Therefore, we should not 
just analyze the way users currently do 
the task, but also the underlying func¬ 
tional reason for the task: What is it that 
really needs to be done? What are merely 
surface procedures that can, and per¬ 


haps should, be changed? At the same 
time, there is a limit to how drastically 
we can change the users’ task, so the 
functional analysis should be coordi¬ 
nated with the task analysis. 

Evolution of the user. Users do not 
stay the same. Using the system changes 
the users, and as they change, they use 
the system in new ways that are impos¬ 
sible to forecast completely. Users will 
always discover new uses for computer 
systems, and a flexible design stands a 
better chance of supporting these new 
uses. Thus, we should make an educat¬ 
ed guess about future users and uses, 
based on our knowledge about how oth¬ 
er users have changed in the past. One 
way of getting such knowledge is through 
the postdeployment field studies rec¬ 
ommended as the last step of the usabil¬ 
ity process. 

A typical change is that users eventu¬ 
ally become experts and want interac¬ 
tion shortcuts (sometimes called accel¬ 
erators). It is important to avoid 
designing only for the way users will use 
the system in the first short period after 
its release. 

Competitive analysis. Prototyping is 
an important part of the usability pro¬ 
cess, and existing — perhaps competing 
— products are often the best proto¬ 
types of our own product. We should 
analyze existing products heuristically 
according to established usability guide¬ 
lines (discussed in the next section) and 
perform empirical user tests with these 
products. 

A competing product is already fully 
implemented and can therefore be test¬ 
ed very easily. Also, its developers of¬ 
ten put a reasonable effort into their 
development process, so the competing 
product may work fairly well. User test¬ 
ing with an existing product can be more 
realistic than a test of other prototypes. 
By having users perform real tasks on 
the competing system, we can learn how 
well its functionality and interaction 
techniques support the kinds of tasks 
we expect the planned new product to 
support. 

If several competing products are 
available, we can do a comparative anal¬ 
ysis of the different approaches to the 
user interface design issues we’re study¬ 
ing. This will provide ideas for the new 
design and ad hoc guidelines for ap¬ 
proaches that seem to work and others 
that should be avoided. 
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A competitive analysis does not im¬ 
ply using other people’s copyrighted 
designs. We hope to do better as a result 
of analyzing their strengths and weak¬ 
nesses. 

Setting usability goals. The five main 
usability characteristics are 

• learnability, 

•efficiency of use once the system 
has been learned, 

• ability of infrequent users to return 
to the system without having to learn 
it all over, 

• frequency and seriousness of user 
errors, and 

• subjective user satisfaction. 

Obviously, these five parameters can¬ 
not be given equal priority in any single 
design, and clear priorities, based on 
the analysis of the users and their tasks, 
should be set. For example, high learn¬ 
ability would be especially important if 
new employees were constantly being 
brought in on a temporary basis. The 
ability of infrequent users to easily re¬ 
turn to the system would be especially 
important for a system-reconfiguration 
utility used once every three or four 
months. In many cases, however, the 
five usability characteristics tend to be 
positively correlated rather than in con¬ 
flict, so getting good results on all of 
them is normally a reasonable goal. 

Usability goals should be specified in 
more detail than the five general usabil¬ 
ity parameters, and doing so is an im¬ 
portant part of the usability process. 
Not all the goals we specify have to be 
measured, but just knowing (and agree¬ 
ing on) goals helps clarify the design 
process. Important goals should be spec¬ 
ified in more detail than less important 
goals, and some goals should be speci¬ 
fied in sufficient detail to allow empiri¬ 
cal measurement of the degree to which 
the product achieves these goals. 

The development team should par¬ 
ticipate in defining the goals so that its 
members won’t see usability goals as 
outside interference with their project. 
Developers who buy into the goals will 
be more motivated to fulfill them. 

In specifying usability goals, several 
different levels of the attributes can be 
listed. 2 The most important may be the 
worst acceptable level , because it indi¬ 
cates that the product would be of no 
use if that level of usability is not 
achieved. Furthermore, we should spec- 


Consistency, an important 
usability characteristic, 
should apply across 
all media forming the 
total user interface. 


ify the planned usability level. Addi¬ 
tional levels are the current level of us¬ 
ability observed in competitive systems, 
or in whatever methods users currently 
use to perform the task, and the best 
possible level for the usability attribute. 

As an example, consider the goal for 
user errors in a system for electronic 
submission of expense accounts in a 
company where 10 percent of the paper 
forms have contained errors. That 10 
percent constitutes the current level and 
zero errors the best possible level. Be¬ 
cause expense report errors are not cat¬ 
astrophic, it may not be reasonable to 
specify zero errors as the planned level, 
but 2 percent might be reasonable. Six 
percent may be the worst acceptable 
level since it may not be worthwhile to 
change the reporting procedures unless 
a significant improvement can be ob¬ 
tained. Of course, usability goals should 
be set in a trade-off with any further 
system attributes, so the worst accept¬ 
able user error level might be 15 per¬ 
cent if significant cost savings were ex¬ 
pected from the electronic processing 
of the documents. 


Design stage 

After completion of the predesign 
stages, several steps should be followed 
in carrying out the design process. In 
most cases, we cannot follow a strict 
order of activities because of the funda¬ 
mental need for an iterative design ap¬ 
proach that gradually refines the user 
interface in several passes through the 
design process. 

The main objective of the design phase 
is to arrive at a usable implementation 
that can be released. For this to happen, 
we must meet two further objectives: 
getting a concrete embodiment of the 
design in a prototype that follows estab¬ 
lished usability principles, and empiri¬ 


cally verifying the design with real users 
to ensure that it meets their needs. 

Participatory design. Even if we fol¬ 
low the advice to “know the user” be¬ 
fore the design phase, we still cannot 
know the user completely enough to 
answer all issues that will come up. In¬ 
stead of guessing, designers should have 
access to a pool of representative users 
after the start of the design phase. Fur¬ 
thermore, users often raise questions 
that the development team has not even 
dreamed of asking. This is especially 
true with respect to potential mismatches 
between the users’ actual task and the 
developers’ model of the task. There¬ 
fore, users should be involved in the 
design process through regular meet¬ 
ings between designers and users. 

Users are not designers, so we should 
not expect them to come up with design 
ideas from scratch. However, they are 
very good at reacting to concrete de¬ 
signs that they do not like or that will 
not work in practice. To get the full 
benefit of user involvement, we must 
present the suggested system designs in 
a form the user can understand. Instead 
of voluminous system specifications, use 
concrete and visible designs, preferably 
in the form of prototypes. In the early 
stages of the design, when functional 
prototypes are not yet available, paper 
mock-ups or a few screen designs can 
prompt user discussion. Even simple, 
guided discussion can elicit ideas. 

It is important to reach the people 
who will actually use the system, not 
just their managers. For example, in 
developing a computer-aided instruc¬ 
tion system, we need access both the 
teachers and the students. However, 
teachers have an authoritative position 
with respect to the students, so we should 
talk to members of each group sepa¬ 
rately. In any case, it is probably very 
difficult to involve young children di¬ 
rectly in the design. For systems to be 
used by young children, we have to rely 
mostly on empirical testing, not on par¬ 
ticipatory design. 

Coordinated design. Consistency is 
one of the most important usability char¬ 
acteristics. 6 Consistency should apply 
across the different media that form the 
total user interface, including not just 
the application screens but also the doc¬ 
umentation, the on-line help system, 
and any on-line or videotaped tutorials. 
Also, consistency is not measured just 
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at some specific point in time. It should 
apply over successive releases of a prod¬ 
uct so that new releases are consistent 
with their predecessors. Despite its gen¬ 
eral desirability, consistency sometimes 
conflicts with other desirable usability 
characteristics. Some flexibility is nec¬ 
essary to avoid forcing a bad design on 
users for the sake of consistency. 

To achieve consistency of the total 
interface, a centralized authority for each 
development project should coordinate 
the various aspects of the interface. 
Typically this coordinator can be a sin¬ 
gle person, but on very large projects or 
for corporate-wide standards, a com¬ 
mittee may be more appropriate. 

In addition to formal coordination 
activities, it helps to have a shared cul¬ 
ture in the development groups — that 
is, a common understanding of what the 
user interface should be like. Many as¬ 
pects of user interface design (especial¬ 
ly the dynamics) are hard to specify in 
written documents but can be fairly eas¬ 
ily understood from looking at existing 
products following a given interface 
style. Actually, prototyping also helps 
achieve consistency, since the proto¬ 
type is an early statement of the kind of 
interface the project is aiming toward. 
An explicit instance of parts of the de¬ 
sign makes the design details more sa¬ 
lient for developers and encourages them 
to follow similar principles in subse¬ 
quent design activities. 

Consistency can be increased through 
technological means such as code shar¬ 
ing or a constraining development envi¬ 
ronment. When several products use 
the same code for parts of their user 
interfaces, those parts of the interfaces 
will automatically be consistent. Even if 
identical code cannot be used, we can 
provide development tools and librar¬ 
ies that encourage user interface consis¬ 
tency by making it easiest for develop¬ 
ers to implement interfaces that follow 
given guidelines. 

Standards. Interface standards are 
currently a popular approach to achiev¬ 
ing consistency. A standard can be a 
widely followed de facto standard such 
as those promoted by several vendors 
and window systems, or it can be an in- 
house standard. The advantage of a de 
facto standard is that it ensures product 
consistency with a large set of products 
developed by other companies. The 
advantage of in-house standards is that 
they can be tailored to the needs of the 


Use simple and natural dialogue 
Speak the user’s language 
Minimize user memory load 
Be consistent 
Provide feedback 
Provide clearly marked exits 
Provide shortcuts 
Provide good error messages 
Prevent errors 


Figure 2. Nine usability heuristics.' 7 

special kind of application normally 
developed by a specific company. Both 
kinds of standards may increase the re¬ 
use of code and documentation. 

Formal international standards for 
some aspects of user interfaces are apt 
to be promulgated within a few years. 
However, such standards are not likely 
to constrain user interfaces sufficiently 
to form the only basis for consistency. It 
is possible to adopt a general standard 
and supplement it with a set of house 
rules for various design details such as 
graphical look and choice of vocabu¬ 
lary. We could, of course, do with just 
the house style guide and avoid the larg¬ 
er standards, but that would risk longer 
training time for new employees accus¬ 
tomed to the main interface standards. 

Standards and guidelines differ in that 
a standard specifies how the interface 
should appear to the user, whereas a set 
of guidelines provides advice about its 
usability characteristics. (Guidelines are 
discussed in the next section.) A given 
standard should follow most of the tra¬ 
ditional usability guidelines so that in¬ 
terfaces designed according to the stan¬ 
dard will be as usable as possible. For 
example, a guideline may state that us¬ 
ers should always have an easy way out 
from any undesired system state. One 
standard might instantiate that general 
guideline by specifying that an Undo 
command should always be available 
and shown as an icon at the top right of 
the screen. Another standard might fol¬ 
low the same guideline by returning to 
the previous system state whenever the 
user hits the Escape key. 

Product identity. A product identity 
statement is a high-level description of 
what kind of “thing” the product is. It 


specifies the project’s overall goals: what 
the product is supposed to be good for, 
who is going to use it, and what other 
products it will be used with. The prod¬ 
uct identity statement can help coordi¬ 
nate the design because it is a short 
document known by all members of the 
development team. 

The project manager should write 
and review the product identity docu¬ 
ment before the start of the design pro¬ 
cess and then modify it sparingly. 

Guidelines and heuristic analysis. 

Guidelines list well-known principles 
for user interface design that should be 
followed in the development project. In 
any given project, several different lev¬ 
els of guidelines should be used: 

• general guidelines applicable to all 
user interfaces, 

• category-specific guidelines for the 
kind of system being developed (for 

, example, guidelines for window- 
based administrative data process¬ 
ing or for voice interfaces accessed 
through telephone keypads), and 
•product-specific guidelines for the 
individual product. 

General guidelines are often published 
in technical journals or books. Some 
guideline documents contain thousands 
of guidelines, while others are less volu¬ 
minous, comprising tens or hundreds of 
rules. A short set of guidelines (such as 
in Figure 2) is suitable for design inspi¬ 
ration or as a checklist in heuristic eval¬ 
uation, while a large set of guidelines 
can serve as a reference for answering 
specific design questions. 

Since good published guidelines are 
available, in-house development of gen¬ 
eral usability guidelines is seldom worth¬ 
while. Also, a complete set of category- 
specific guidelines can often be found in 
the published literature, but we might 
have to adjust them somewhat to fit the 
precise kind of products being devel¬ 
oped. Finally, the product-specific guide¬ 
lines must, by definition, be developed 
for each project on the basis of observa¬ 
tions of what does or doesn’t work in 
the testing of competitive products and 
initial prototypes. 

One general usability principle is to 
tell the user what is going on by provid¬ 
ing feedback. For example, a file system 
could indicate that a file has been delet¬ 
ed by removing its name or icon from a 
list of current files. A category-specific 
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principle for hypertext systems (see the 
sidebar) is to provide users with a sense 
of location in the information space but 
avoid showing a complete overview 
diagram of all nodes and links if the 
document is too large. For a large elec¬ 
tronic handbook with a strict chapter- 
section-subsection hierarchy, a product- 
specific guideline could then provide 
feedback on the location with a fish-eye 
view showing the current specific loca¬ 
tion against an indented list of the sub¬ 
heading hierarchy. 

It is possible to perform heuristic eval¬ 
uation on the basis of the guidelines. 7 
This is done by going through the inter¬ 
face design and determining whether 


each of its elements follows each of the 
guidelines established for the project. 
The actual activity can take the form of 
formal walk-throughs with elaborate 
checklists, or it can be performed more 
casually. But even the most casual heu¬ 
ristic evaluation should be based on 
some usability guidelines, not just per¬ 
sonal opinion. The advantage of heuris¬ 
tic evaluation is that it can be done in 
the very early design stages because it 
does not require a running system. But 
I stress that heuristic evaluation should 
only supplement empirical testing. 

Usability guidelines often contain 
apparent contradictions that can be dif¬ 
ficult to resolve for people who are not 


usability specialists. To make appropri¬ 
ate trade-offs, we need to understand 
the spirit behind the guidelines, and this 
requires understanding higher level us¬ 
ability principles such as consistency. 
The same is true for applying results 
from the human factors research litera¬ 
ture, since we cannot expect the litera¬ 
ture to contain explicit design decisions. 
Guidelines that contain lists of advan¬ 
tages and disadvantages of various de¬ 
sign approaches can also help us make 
trade-offs, but they are, again, difficult 
to apply for those who are not usability 
specialists. 

In general, the project should have 
access to a usability expert to help re- 


Hypertext 


Hypertext' 2 interconnects related pieces of information in a 
computer so that the user can move to new locations in the 
information space by following the connecting links. The in¬ 
formation is normally divided into units, which are often dis¬ 
played in separate windows on the screen. These units are 
called nodes because the entire hypertext information space 
forms a graph structure. 

Navigation. A major issue in the design of hypertext sys¬ 
tems is how to support the users’ navigation through the in¬ 
formation space. In the example in the figure, users might 
jump directly from node A to node D, or they may take the 
path A->E->D or even the path A-»B->C-»F-»E-»D. Be¬ 
cause of this great freedom in moving about, users can easi¬ 
ly get confused about where they are, where they came from, 
and where they can go. To alleviate these problems, hyper¬ 
text systems often include some kind of overview diagram 
somewhat like the figure, as well as a history facility listing 
the previously visited nodes. 

Fish-eye views. Fish-eye views 3 increase users’ sense of 
location in an information space by showing great detail for 
those parts of the space close to the user’s current location 
of interest and gradually diminishing amounts of detail for 
those parts progressively farther away. The use of fish-eye 
views therefore requires two properties of the information 
space: It should be possible to estimate the distance be¬ 
tween a given location and the user’s current focus of inter¬ 
est, and it should be possible to display the information at 
several levels of detail. This is especially easy to do in a hi¬ 
erarchically structured electronic book in which distant chap¬ 
ters can be displayed by their chapter heading only. Closer 
chapters can show additional levels of section and subsec¬ 
tion headings. 

Applications. The most obvious hypertext application is 
probably on-line manuals. Users of a software package will 
already be at their computers when they want to look up 
something in the manual. For many other applications, the 
need to be at a computer is somewhat of a disadvantage 
compared with the use of printed books — at least given cur- 


Hypertext 

graph 

structure. 


rent computer hardware. Even so, hypertext has many diverse 
applications, including museum and tourist information, elec¬ 
tronic encyclopedias, teaching classic Greek literature, legal 
information for patent lawyers, auditing, brainstorm support, 
programming environments, and games. 

Design rationale. Hypertext can capture the rationale for 
user interface design decisions in a network of interrelated de¬ 
sign issues and arguments pro and con. For example, an is¬ 
sue in the design of a paint program could be whether to 
present the various colors as a permanently visible palette or 
a pop-up menu, or to have the user explicitly type in the color 
mixture as percentages of red, green, and blue. There would 
be one hypertext node for the overall issue of color selection, 
with links to separate nodes for each possible solution. These 
nodes would have small sketches of how each interface de¬ 
sign would look, and they would be linked to further nodes 
with the results of any user testing or heuristic evaluation. Be¬ 
cause user interface decisions affect one another, there would 
also be links to, say, nodes about the use of screen space: 
The possible decision to use a permanently visible palette 
would diminish the space available for other interface ele¬ 
ments and the primary drawing window. 
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solve contradictory guidelines and to 
help in heuristic evaluation. Although 
different usability experts may give dif¬ 
ferent advice, this does not necessarily 
imply that at least one of them is wrong. 
There are so many degrees of freedom 
in user interface design that several so¬ 
lutions may be more or less equally 
reasonable. 

Prototyping. Experimental prototyp¬ 
ing is highly recommended for the early 
stages in the design process. For soft¬ 
ware systems, we should “plan to throw 
one away” 8 because the first design will 
never be good enough. If anything, this 
advice is truer of interfaces than of oth¬ 
er components because of the greater 
difficulty of predicting their flaws. It is 
less expensive to throw away a proto¬ 
type than a completely implemented, 
fully functional system. 

In traditional software engineering 
models, most of the development time 
is devoted to refining various interme¬ 
diate work products, and executable 
programs are produced at the last possi¬ 
ble moment. A problem with this ap¬ 
proach is that there is no user interface 
to test with real users until this last 
possible moment, because the “inter¬ 
mediate work products” do not explic¬ 
itly separate the user interface in a pro¬ 
totype with which users can interact. 
Experience also shows that it is not 
advisable to involve the users in the 
design process by showing them abstract 
specifications documents; they do not 
understand documents nearly as well as 
concrete prototypes. 

It’s best to postpone final implemen¬ 
tation until late in the development pro¬ 
cess so that it can be done on the basis of 
experiences with the prototypes. The 
early prototypes can be quite primitive 
(for example, paper mock-ups), where¬ 
as later prototypes can be progressively 
closer to the final product. Often we can 
gain substantial insights from low-fidel¬ 
ity prototypes, 9 so it is probably better 
to prototype early and prototype often 
than to put an extensive effort into a 
single, elaborate, and (too) late proto¬ 
type. Even computerized prototypes 
may be implemented faster and cheap¬ 
er in systems other than the eventual 
delivery platform, and implementation 
time can sometimes be reduced by 
“cheating” on the algorithms to make 
them ignore the special cases that often 
take an inordinate amount of program¬ 
ming effort. 


Prototype early and 
prototype often to avoid 
putting extensive effort 
into a single, elaborate, 
(too) late prototype. 


Empirical testing. The most basic rec¬ 
ommendation for empirical testing is 
simply to do it. The benefits of doing 
some user testing versus doing no user 
testing are much greater then the differ¬ 
ential benefits of various approaches to 
testing. 

There are two basic forms of empiri¬ 
cal testing: 

(1) Testing a more or less finished 
interface to check whether the usability 
goals have been achieved. This kind of 
testing implies doing some form of quan¬ 
titative measurement. 

(2) Formative evaluation of a system 
still being designed to see which aspects 
of the user interface work and which 
cause usability problems. This kind of 
testing is often best done using qualita¬ 
tive methods. At this stage, it is more 
important to know why the interface is 
wrong than how much it is wrong. 

In both cases, it is important to have the 
test users perform tasks representative 
of the eventual use indicated by the 
predesign task analysis. 

Some of the more common test meth¬ 
ods are 

• Thinking aloud (see the sidebar). 

• Constructive interaction (sometimes 
called codiscovery learning). In this 
method, two users work together to 
perform the test task. This approach is 
better than traditional thinking aloud 
when the test subjects are children, 
because verbalizing comes more natu¬ 
rally in a two-user setting. Even adults 
often find this method more natural, 
but it does have the obvious disadvan¬ 
tage of requiring twice as many test 
users. 

•Attitude questionnaires in which 
users rate designs on, say, a 1 to 5 scale. 

• Tests of the user’s level of knowl¬ 
edge (or other user skills) before and 
after using the system. 


• Automatic computer logging of user 
actions. Later analysis can determine, 
say, that a certain error message is is¬ 
sued so frequently that the “prevent 
errors” usability guideline should be 
applied to reduce the probability of the 
corresponding error situation. 

• Observation of users working in their 
natural environment with their own 
tasks. 

• Observation of users working on a 
set of representative standard tasks. 

The last two methods are especially suit¬ 
ed for follow-up tests of released prod¬ 
ucts or for tests of prototypes that are 
complete enough to allow users to do 
real work. 

From the results of the empirical tests, 
we obtain a list of usability problems in 
the test version, as well as hints for 
features to support successful user strat¬ 
egies. It’s not feasible to solve all the 
problems, so we prioritize them. The 
ranking should be based on experimen¬ 
tal data about the impact of the prob¬ 
lems on user performance (for exam¬ 
ple, how many people will experience 
the problem and how much time each of 
them will waste because of it). 

But sometimes we must rely on intu¬ 
ition only. In some cases, solving a prob¬ 
lem may make the interface worse for 
those users who do not experience the 
problem. Then a trade-off analysis is 
necessary to determine whether to keep 
or change the interface, based on a fre¬ 
quency analysis of how many users will 
have the problem compared with how 
many will suffer because of the pro¬ 
posed solution. 

The time and expense needed to fix a 
particular problem is also a factor in 
determining priorities. Often, usability 
problems can be fixed by changing the 
wording of a menu item or an error 
message. Other design fixes may in¬ 
volve fundamental changes to the soft¬ 
ware (which is why they should be dis¬ 
covered as early as possible) and will be 
implemented only if they are judged to 
affect usability significantly. 

Iterative design. On the basis of the 
usability problems and opportunities 
disclosed by the empirical testing, we 
can produce a new version of the inter¬ 
face. Some testing methods, such as 
thinking aloud, provide sufficient in¬ 
sight into the problems to suggest spe¬ 
cific changes to the interface. In other 
cases, alternative potential solutions 


18 


COMPUTER 







need to be designed solely on the basis 
of usability guidelines, and it may be 
necessary to test several possible solu¬ 
tions before making a decision. Famil¬ 
iarity with the design options, insight 
gained from watching users, creativity, 
and luck are all needed at this point. 

Some of the changes we make to solve 
certain usability problems may fail to 
solve the problems or even introduce 
new ones. This is another reason for 
doing iterative design and evaluation. 

Retesting. Additional usability prob¬ 
lems will likely appear in repeated tests 
after the most blatant problems have 
been corrected. There is no need to test 
initial designs comprehensively since 
they will be changed anyway. We should 
change and retest the user interface as 
soon as we detect and understand a 
usability problem so that we can find 


the remaining problems that were 
masked by the initial glaring problems. 

During the iterative design process it 
may not be feasible to test each succes¬ 
sive version with actual users. The iter¬ 
ations are a good way to evaluate design 
ideas simply by trying them out in a 
concrete design. We can then subject 
the design to heuristic analysis and show 
it to usability experts and consultants, 
or discuss it with expert users (or teachers, 
in the case of learning systems). 

We should not “waste” users by per¬ 
forming elaborate tests of every single 
design idea. Test subjects are normally 
hard to come by and should be con¬ 
served for the testing of major itera¬ 
tions. Also, users get “worn out” as ap¬ 
propriate test subjects. As they get more 
experience with the system, they stop 
being representative of novice users see¬ 
ing the design for the first time. Users 


who have been involved in participatory 
design are especially inappropriate 
as test subjects because they will be 
biased. 

Design rationale. The rationale for 
the various user interface design deci¬ 
sions can be made explicit and recorded 
either in traditional written form or in a 
hypertext structure such as gIBIS. 10 
Having access to such an audit trail is 
important during iterative development 
and during development of any future 
product releases. Because we will often 
have to change the interface, we should 
know the reasons for the original design 
to avoid sacrificing important usability 
principles to attain a minor objective. 
Furthermore, the design rationale can 
help in maintaining user interface 
consistency across successive product 
versions. 


Thinking aloud 


Thinking aloud is a commonly recommended method for 
user testing that can be used for almost any system, so I 
present it in somewhat more detail than the other methods 
mentioned in this article. Many of the recommendations also 
apply to other forms of user testing. 

Basically, a thinking-aloud test involves having a test sub¬ 
ject use the system while continuously thinking out loud. 

While verbalizing their thoughts, the test users reveal their 
view of the computer system, and this lets us identify their 
major misconceptions. We get a very direct understanding of 
what parts of the dialogue cause the most problems, because 
the thinking-aloud method shows how users interpret each in¬ 
terface item. 

The thinking-aloud method has traditionally been used as a 
psychological research method, 1 but it is increasingly being 
used for the practical evaluation of human-computer interfac¬ 
es. 2 Studies have shown 3 that computer professionals can 
use the thinking-aloud method to good effect. Often, it is 
enough to run a fairly small number of test users (4±1) to find 
most usability problems. The main disadvantage of the think¬ 
ing-aloud method is that time measurements will not be repre¬ 
sentative of real usage because verbalizing thoughts and an¬ 
swering questions will slow down the user. 

Test tasks. The experimenter must prepare a set of tasks 
for the test user, since the experience of using an application 
differs significantly depending on whether the user is just fool¬ 
ing around or is trying to achieve a set goal. We are normally 
interested in testing the usability of software to achieve a 
goal. The tasks should be chosen to reflect typical, serious 
usage situations. 

Running the test. Unfortunately, it is rather unnatural for 
most people to continuously verbalize their thoughts. There¬ 
fore, the experimenter often needs to prompt the test user 


with questions like “What are you thinking now?” or “How do 
you interpret this error message?” The experimenter should 
not answer any questions asked by the user because the test 
aims at assessing how easy the user interface is to use with¬ 
out outside help. To increase the test user’s confidence, the 
experimenter should ensure an early success experience by 
having the very first assignment be extremely easy. 

ethical considerations. Test results from individual users 
should be kept confidential. It would immediately ruin any 
constructive atmosphere if, say, the users’ manager was to 
use test scores to assess their computer skills. Even so, test 
users will always feel as though they are taking an exam, and 
they will feel stupid whenever they make mistakes. To reduce 
the unpleasantness of the test, experimenters should inform 
the test users that they are not testing the users but that they 
are testing a preliminary software design that is bound to 
have some problems. Finally, test subjects should be allowed 
to discontinue the test at any time if they find it too unpleas¬ 
ant (their natural pride will ensure that they will almost never 
do so). 
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Postdesign stage 

The main objective of usability work 
after product release is to gather data 
for the next version and for new future 
products. In the same way that existing 
and competing products were the best 
prototypes for the product in the initial 
competitive analysis phase, a newly re¬ 
leased product can be viewed as a proto¬ 
type of future products, and in most 
cases it is certainly the prototype of its 
own next release. Therefore, we must 
not end the usability process with the 
initial release of the product to the mar¬ 
ketplace; we need to conduct follow-up 
studies of product use in the field. Such 
studies assess how real users use the 
interface for naturally occurring tasks in 
their real-world working environments 
and can lead to insights not readily avail¬ 
able from laboratory studies. 

A simple way to obtain feedback from 
users of installed products is to log user 
calls to hot lines or other product-sup¬ 
port structures. It is important to go 
beyond simply recording immediate 
complaints and classify the problems to 
determine patterns and likely root caus¬ 
es. However, this only provides feed¬ 
back about problems. To learn about 
the system’s positive aspects — and its 
new, unexpected uses — we need to 
visit real users in their everyday work 
environments. Also, logging user ses¬ 
sions with the installed system is a good 
way to obtain field data on system use. 

Finally, economic data on the sys¬ 
tem’s impact on the quality and cost of 
the users’ work product and quality of 
their work life are very important. We 
can gather these data through surveys, 
supervisor opinions, statistics for ab¬ 
senteeism, and so on. These data should 
be compared with similar data collected 
before the introduction of the system. 

Life cycle model 
summary 

Look again at Figure 1, the outline of 
activities recommended in our usability 
engineering process, and note that some 
of the recommended methods are not 
really single “steps” but should be used 
throughout the process. 

Costs. Obviously, there is some cost 
associated with following the recom¬ 


mended usability engineering process, 
even though we can significantly reduce 
these costs by concentrating on a subset 
of the methods. But usability is not just 
a cost item in a development project, 
even though the “benefits” side of the 
cost-benefit trade-off is articulated with 
comparatively poor precision and evi¬ 
dence in the usability literature." (One 
documented case study shows savings 
of $41,700 in reduced training time for 
one small in-house product as a result of 
a $20,700 usability effort. 12 ) 

The financial payoff associated with 
users’ ability to learn the product faster 
and work more productively is spread 
over the entire period of product use 
and is therefore hard to measure pre¬ 
cisely. And these benefits are certainly 
not explicitly visible during develop¬ 
ment. A major benefit for the develop¬ 
ment team itself, however, is the time 
saved in not implementing features that 
the usability analysis shows are not need¬ 
ed by users. Furthermore, in many situ¬ 
ations usability is a major marketing 
consideration, and an otherwise accept¬ 
able product will fail completely if it is 
not perceived as usable by customers. 

In any case, the cost-benefit relation 
may be drastically changed when con¬ 
sidered in the context of the entire prod¬ 
uct life cycle rather than a single-re¬ 
lease context. This is especially true if 
we take the even broader corporate 
perspective of multiproduct develop¬ 
ment. 5 A benefit of early usability ef¬ 
forts may manifest itself in fewer cus¬ 
tomer modification requests if users’ 
needs are matched better from the start. 
Another benefit may be the ability (and 
willingness) of users to learn and adopt 
additional products if they are easier to 


Metamethods. To ensure the success¬ 
ful application of the usability engineer¬ 
ing methods discussed here, it is impor¬ 
tant to supplement each with the 
following “metamethods” (methods that 
apply to methods): 

• Write down an explicit plan for what 
to do when using the method. For exam¬ 
ple, a plan for empirical user testing 
should include information about how 
many users to test, what kind of users to 
test (and how to get them), what test 
tasks these users will be asked to per¬ 
form (which itself should be based on 
task analysis and user observation), and 
a time schedule for the studies. 


• Subject this plan to an independent 
review by a person who is not otherwise 
on the development team and who can 
critique it from a fresh perspective. Of 
course, this person should be experi¬ 
enced in usability engineering. 

• Perform a pilot activity by investing 
no more than about 10 percent of the 
total resources budgeted for the use of 
the method. Then revise the plan for the 
remaining 90 percent to fix the difficul¬ 
ties that invariably will be found during 
the pilot activity. In empirical user test¬ 
ing, users often misinterpret the origi¬ 
nal test tasks, so be sure that the main 
test focuses on system usability, not on 
the developers’ ability to write readable 
test instructions. 

As early as possible in the project, 
establish an overall usability plan listing 
the usability activities to be performed 
throughout the life cycle. Not all projects 
can afford to use all the methods, and 
the exact methods to use will depend on 
the project characteristics. 

These metamethods may involve a 
little extra work up front, but they save 
work in the long term and ensure that 
our efforts are on the right track to 
increase usability, thereby reducing the 
risk of truly wasting the main effort. 

Prioritizing usability 
methods 

As a reality check on the practical 
applicability of the usability methods 
suggested above, I asked 13 usability 
engineers to complete a questionnaire. 
For each of the methods listed in Table 
1, the questionnaire asked whether they 
had used it in their most recent develop¬ 
ment project and what impact they felt 
the method had on usability in general 
(no matter whether they had used it in 
their latest project). The respondents 
were people actively engaged in usabil¬ 
ity engineering and therefore the num¬ 
bers in Table 1 are not representative of 
all development projects. On the con¬ 
trary, most development projects do not 
currently have usability engineers on 
the development team, and prior re¬ 
search 1 has shown extraordinarily low 
use of usability methods in average de¬ 
velopment projects. 

The engineers evaluated the meth¬ 
ods’ impact according to the following 1 
to 5 scale: 
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Table 1. List of usability engineering methods showing the extent to which development projects actually used each method 
as well as the average rated importance of each method on a 1 to 5 scale: 1 indicates no impact and 5 indicates absolutely essential. 
The list of methods is ordered according to the approximate placement of the methods in the usability life cycle. 


Activity or Method 

Used on 
Project 
(percent yes) 

Impact on 
Usability 
in General 
(average) 

Visit to customer location before start of design 

92 

4.3 

Task analysis of user’s current task 

69 

4.7 

Functional analysis of reason for user’s task 

46 

3.8 

Projection of evolution in user needs and abilities 

54 

3.4 

Competitive analysis: Looking at existing competing products 

77 

2.9 

Competitive analysis: Comparative analysis of competing products 

23 

2.8 

Competitive analysis: User testing of competing products 

23 

3.1 

Goal setting: Explicit priorities between usability parameters 

38 

3.3 

Goal setting: Measurable levels specified for important goals 

38 

3.5 

Participatory design: Real users involved during the design process 

85 

4.4 

Coordination of the “traditional” user interface (screens, messages, and so on) 

69 

4.2 

Coordination of the “total” user interface (manuals, training, and so on) 

38 

4.1 

Use of a published vendor (or other de facto) interface standard 

23 

2.4 

Use of in-house user interface standard or house style 

69 

3.5 

Specification of a product identity 

38 

3.1 

Use of large, general guidelines book 

38 

2.6 

Use of category-specific guidelines for the type of product being developed 

31 

3.1 

Listing and use of product-specific guidelines for the individual product 

54 

3.3 

Heuristic evaluation (informal judgment based on guidelines) 

46 

3.3 

Prototyping: Construction of paper mock-ups 

46 

3.0 

Prototyping using computer tools 

85 

3.9 

Empirical testing with real users as subjects 

69 

4.5 

Measurements taken during test and compared with goals 

31 

3.3 

Thinking-aloud experiments 

31 

3.1 

Constructive interaction (two users work together) 

38 

3.3 

Videotaping of user testing (as opposed to just taking notes) 

23 

2.9 

Questionnaires to assess user attitudes toward the system 

38 

2.7 

Iterative design 

85 

4.7 

Explicit documentation of the rationale for the user interface design 

46 

3.3 

Feedback from field use: Record user calls to hot line and so on 

54 

3.3 

Method exists for users to provide direct feedback to developers 

54 

3.8 

Field study/visit to customers to find out how the system is actually used 

46 

4.3 

Logging of user actions on the system 

38 

3.0 


(1) No impact on usability; it does not 
matter whether this is done or not. 

(2) Small impact, but of no real impor¬ 
tance. 

(3) Medium (and real) impact on im¬ 
proving usability. 

(4) Major impact on usability; should 
be done in most cases. 

(5) Absolutely essential for improving 
usability; should be done in all cases. 

The reason for surveying usability 
engineers instead of regular developers 


was to collect views founded on actual 
experience with the methods. Even if 
we cannot include a full-fledged usabil¬ 
ity engineering methodology in our de¬ 
velopment life cycle, we should at least 
choose the methods that usability engi¬ 
neers use or recommended the most. 
Actually, almost all the methods got an 
impact rating of at least 3, indicating 
that they were all judged as having a 
real impact on usability. The best ap¬ 
proach would be to use as many meth¬ 
ods as possible. But even if we have only 


limited resources to invest in usability, 
we should still consider some of the 
most important methods. 

The top five methods according to 
frequency of actual use by the usability 
engineers are 

(1) Visit to customer location before 
start of design. 

(2-4) Iterative design, participatory 
design, and prototyping using comput¬ 
er tools. 
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(5) Competitive analysis: Looking at 
existing competing products. 

The top six methods according to rat¬ 
ed impact on usability are 

(1-2) Iterative design and task analy¬ 
sis of the user’s current task. 

(3) Empirical testing with real users 
as subjects. 

(4) Participatory design. 

(5-6) Visit to customer location be¬ 
fore start of design and field study/visit 
to customers to find out how the system 
is actually used after installation. 

There is considerable overlap between 
the two lists, and there is in general a 
fairly high correlation between the use 
of the methods and their rated impact 
(R = 0.71). The three methods having 
the largest residuals in the regression 
analysis (indicating a mismatch between 
the scores on the two scales) are 

• Competitive analysis: Looking at 
existing competing products. This seems 
to be done too much compared with the 
fairly low rated impact. From the im¬ 
pact rating, the regression “predicted” 
only 33 percent use. 

• Coordination of the “total” user in¬ 
terface (not just screens but also manu¬ 
als, training, and so on). This is done 
much too little compared with the high 
rated impact. From the impact rating, 
the regression “predicted” 64 percent 

• Field study/visit to customers to find 
out how the system is actually used. This 
is done too little compared with the 
high rated impact. From the impact rat¬ 
ing, the regression “predicted” 69 per¬ 
cent use. 


T he usability engineering life 
cycle requires the use of a large 
large number of usability 
methods to follow the complete set of 
recommendations given here. Often 
budget or time constraints will not al¬ 
low the use of all the methods, but I 
recommend the following as a mini¬ 
mum: 

• visit customer locations before the 
start of the project, 

• do iterative and participatory de¬ 
sign, and 

• use prototyping and empirical tests 
with real users. 


The single most important advice re¬ 
garding usability engineering is simply 
to get started now. It is easy to get so 
overwhelmed by the complete usability 
engineering life cycle that we decide to 
wait until the next project, in which 
there will surely be more time for us¬ 
ability considerations. Unfortunately, 
the “next time” can easily be put off 
again and again. Instead, we should start 
with a few of the simpler methods right 
away and then gradually extend the 
scope of usability activities until the 
entire life cycle is covered. Such a grad¬ 
ual approach is more likely to succeed 
than an “all-or-nothing” approach. 

The world is full of useless and frus¬ 
trating software with functionality and 
user interfaces that could have been 
improved if their designers had used 
current usability engineering methods. 
The world is even full of frustrating 
alarm clocks, video recorders, and oth¬ 
er appliances that could stand a dose of 
usability engineering. Please don’t let 
your users suffer needlessly. ■ 
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Sound Works: 

An Object-Oriented 
Distributed System 
for Digital Sound 


Jonathan D. Reichbach and Richard A. Kemmerer 
University of California at Santa Barbara 


SoundWorks lets users 
interactively manipulate 
sound through a 
graphical interface. 
The system handles 
digitally sampled 
sounds as well as those 
generated by software 
and digital signal 
processing hardware. 


T 1 he field of computer-based music encompasses issues in music composi- 
1 tion, synthesis, manipulation, and performance. 15 Here, we address the 
manipulation and synthesis of sounds. Our primary goal in this work was 
to provide standard sound manipulation (or editing) features like splicing, looping, 
and mixing. In so doing, we provided operations that could modify the amplitude, 
pitch, and duration of sounds. To aid in modifying sounds — and creating new ones 
— we predefined sounds representing basic sound-generating waveforms (for 
example, sine and triangle) for use with available operations. 

Our second goal was to develop a server-based system that could be easily 
integrated with other applications and user interfaces, and that could be extended 
to support network-based access to sounds and devices. We addressed the large 
computational requirements of digital sound manipulation by integrating digital 
processing hardware into the system. This integration supports a more interactive 
environment for processing sounds and provides the possibility of real-time 
response. 

Because we wanted to have a server-based system with network-based access to 
sounds and digital processing hardware, we used Sun Microsystems’ NEWS 
application programming environment 6 for developing the system. NEWS (which 
stands for network-extensible window system) provided the necessary primitive 
graphic items for a graphical window-based interface and let us use an object- 
oriented approach for development. 

The resulting system, called SoundWorks, is an object-oriented distributed 
system for manipulating digital sound. It lets the user interactively manipulate 
these sounds with a graphical window-based interface and handles digital sampled 


0018-9162/92/0300-0025S03.00 © 


March 1992 


1992 IEEE 


25 









sounds, sounds generated by software, 
or sounds generated by digital signal 
processing hardware. SoundWorks’ dis¬ 
tributed nature lets the sounds and dig¬ 
ital hardware reside on a system other 
than the user’s local system. 

After a brief description of related 
research that provided the basis for 
SoundWorks, we introduce the Sound- 
Works system and present details about 
its design. Then we summarize the re¬ 
sults of the project and discuss some 
areas for future research. 


Related research 


User interface design for sound pro¬ 
cessing has followed the trend for tradi¬ 
tional applications. It progressed from 
punch cards and teletypewriter-based 
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I terminal interfaces to graphics-based 
window interfaces. These developments 
paralleled a transition from batch pro- 
I cessing to more interactive environ¬ 
ments. Also, with the advent of distrib¬ 
uted systems, sound processing systems 
I could be distributed to allow multiple 
| users to share resources such as sound 
file systems and digital sound process¬ 
ing hardware. 

User interfaces. Two issues impor¬ 
tant in developing a graphical user in¬ 
terface are consistency between the 
graphics model and the objects in the 
f system, and compatibility with other 
I graphics applications. A consistent sys- 
I tem graphics model provides a close tie 
between objects and their correspond¬ 
ing graphic representations. For in- 
| stance, a sound object can be displayed 
as a waveform, representing the change 
in amplitude over time. 

This close tie should also extend to 
I other objects in the system. For exam- 
! pie, the graphic representation of a win- 

j dow should be consistent with that win¬ 
dow’s function, regardless of whether 
the window is open or closed. In Sound- 
Works we achieved this by using the 
I same icon in different sizes to represent 
all windows that contain a sound. That 
is, a sound window can be either open, 
exposing the contents of the window, or 
I closed, with an icon representing the 
j contents of the window. Similarly, the 
help window icon is a picture of a text 
| manual. The main goal is that the graphic 

objects, regardless of their state, repre- 
* sent the objects in the system. 

Compatibility with other applications 
can be achieved with a graphics win¬ 
dow-mouse package. This package pro- 
j vides a basic set of graphic objects (win¬ 
dows, menus, buttons, message boxes, 
and so on) that can be integrated with 
application-specific graphic objects. 
Developers can also provide a set of 
standard graphic objects representing 
sound-related objects. The HyperScore 
ToolKit, 7 MacMix, 2 and Sound Kit 3 are 
good examples of packages tailored to¬ 
ward sound applications. These systems 
provide a basic set of extensible graphic 
I objects for displaying sounds, notes, 
and other application-specific informa- 
[ tion. 

Following this approach, SoundWorks 
| provides a set of graphic objects that 
can be used to represent and manipu¬ 
late sounds. These graphic objects are 
easily extended and modified to pro¬ 


vide a high-level interface for integrat¬ 
ing audio and graphics. 

Distributed sound systems. These re¬ 
cently developed systems provide bet¬ 
ter resource-sharing, reliability, and 
performance at lower cost. Some recent 
digital sound systems provide shared 
access to resources using local area net¬ 
works. For instance, the Etherphone 
system 8 for network-based voice mes¬ 
sages lets the user edit digital voice rep¬ 
resentations and play or record the re¬ 
sult through special-purpose hardware 
at a local workstation. The Vox server, 9 
in contrast, provides flexible configura¬ 
tions of digital hardware, such as speech 
synthesis, speech recognition, and vid¬ 
eo devices, which can be integrated with 
the user’s local workstation. These de¬ 
vices can also be shared across the net¬ 
work. 

The SoundWorks user interface, 
which resides on the user’s local system, 
is distributed from the application code, 
which resides on the remote system 
where the sound files and hardware are 
located. The local graphic interface code 
interacts with the user, and the remote 
application code manages the sounds, 
implements all operations, and inter¬ 
faces with devices. Currently, Sound- 
Works distributes only the user inter¬ 
face to the sound files and hardware. 
However, the architecture of Sound- 
Works can be extended to let multiple 
users access shared sound files and dig¬ 
ital sound hardware throughout the net¬ 
work. 


System overview 

This section presents the different 
types of sounds and window interfaces 
provided by SoundWorks and the oper¬ 
ations that modify these sounds. 

Sounds and sound windows. Sound- 
Works provides two types of sound: sam¬ 
pled and generated. Sampled sounds are 
stored on disk as a series of numbers 
representing the change in amplitude 
over time, while generated sounds are 
computed as required by software or 
external hardware. Sounds are access¬ 
ed through file sound windows and wave 
sound windows. A third type of win¬ 
dow, the line segment window , is used to 
modify other sounds. Line segment win¬ 
dows allow users to define linear func¬ 
tions. A linear function is a software¬ 


generated sound of only one cycle. 

In the remainder of this article, we 
classify all three windows as sound win¬ 
dows. Each type of window supports a 
common set of controls and operations. 
Each type also has unique controls and 
operations. An example of a common 
operation is setting edit markers that 
delimit a section of sound or a line in a 
window. In contrast, the save opera¬ 
tion, which saves a sampled sound on 
disk, is available only for file sound 
windows, even though line segments 
could also be saved. 

File sound windows are used for ac¬ 
cessing sound files, which are stored on 
disk as a series of samples. Figure 1 
shows two example file sound windows. 
The sounds represented in these win¬ 
dows are identified by name, starting 
point, and duration. Figure la shows a 
mono sound, and Figure lb a stereo 
sound. Sound files can have different 
sample rates and can be any length in 
duration. Users can create sounds in a 
variety of ways. They can sample sounds 
from an external analog audio source, 
compute sounds with a direct synthesis 
language, or create sounds with a Sound- 
Works operation. 

Common editing commands, such as 
deleting and repeating sections of a 
sound and changing its amplitude and 
duration, are accessed through the file 
sound window menu. The example in 
Figure la has edit marks (vertical lines 
perpendicular to the sound) that delim¬ 
it the section of sound starting at time 
0.249878 and ending at time 0.641602 
seconds. Figure 2 shows the mono file 
sound window of Figure 1 a with the edit 
window indicating that the delete oper¬ 
ation will be applied to the left section 
of the sound. 

Operations on sound files are made 
to an internal copy of the sound and do 
not affect the original version stored on 
disk. The save operation stores a sound 
file on disk. Sounds can also be manip¬ 
ulated by using operation windows, 
which are described in the next section. 

Wave sounds, which are basic sound 
units, can be used as building blocks for 
creating new sounds. Four types of wave 
sounds are provided: sine, triangle, saw¬ 
tooth, and square. Before users can ac¬ 
cess these sounds, they must specify the 
type of wave, frequency, amplitude, and 
duration. In contrast to sound files, wave 
sounds are not stored on disk, but are 
computed by the system as required. As 
a result, wave sounds are not modified 
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Figure 3. Wave sound window. 


Figure 4. Line segment window. 


after they are created. Fig- ' ~ 
ure 3 shows an example wave 
sound window for a sine 
wave. 

A variant of the wave § 
sound generates sound 
through digital signal pro¬ 
cessing (DSP) hardware. In¬ 
stead of a wave type, the user 
specifies a program execut¬ 
ed by the DSP hardware. 

When the user invokes the ——- 

program, it generates the Figure 5. 
sound. For example, a user 
can specify a line segment 
window as the waveform shape to pro¬ 
duce a wave sound. 

Line segment windows are used to 
create line segments for manipulating 
sounds. For example, line segments may 
be used to modify the amplitude and 
duration of file or wave sounds. Figure 
4 shows an example line segment win¬ 
dow. 

Operation windows. In addition to 
the editing commands accessed through 
the menu of a sound window, the Sound- 
Works system provides a set of opera¬ 
tions that uses either a sound or a line 
segment to manipulate another sound. 
Users access these operations through 
separate windows that guide them 
through the operation, asking them to 
choose the source, the modifier, and 
other necessary information. The oper¬ 
ation windows can be used to splice and 
mix sounds as well as to modify the 
amplitude and duration of a sound by 
another sound. For example, a line seg¬ 
ment can be used as an amplitude enve¬ 
lope to modify a sound. Figure 5 shows 
a merge operation window at the start 



Operation window. 


of the system’s interaction with the user. 

Figure 6 shows the input and output 
windows for a mix operation. The win¬ 
dows in Figures 6a and 6b are wave 
sound windows. The left one is the source 
window, and the right is the modifier. 
Because wave sounds cannot be modi¬ 
fied once created, the user must create 
a new window to contain the result of 
the operation. To do this, the user choos¬ 
es the “new” button in the operation 
window (Figure 5). The window in Fig¬ 
ure 6c shows the result of mixing the 
center section of the source sound with 
the wave sound and using the result to 
replace the center section. Currently, 
SoundWorks supports the use of only 
two sounds in operations. The capabil¬ 
ity for supporting any number of these 
sounds would be a reasonable exten¬ 
sion. 

SoundWorks design 

To design and develop SoundWorks, 
we used an object-oriented version of 
PostScript in addition to Sun Microsys¬ 


tems’ NEWS application pro¬ 
gramming environment. Be¬ 
fore describing the high-lev¬ 
el architecture and the design 
of the SoundWorks system, 
we briefly describe the 
NEWS application environ¬ 
ment. 

I NEWS. Sun Microsys¬ 

tems developed NEWS 6 

- to provide class structures 

that support an object- 
oriented approach for pro¬ 
ducing graphical interfaces. 
Through an object-oriented version of 
PostScript, NEWS provides a set of ba¬ 
sic graphic items and an underlying 
framework for integrating these items 
into application-specific code. That is, 
graphic items are defined as a collection 
of classes, which can be either integrat¬ 
ed into the application as is or modified 
by using inheritance. In SoundWorks 
we used predefined graphic items as the 
basis for defining a set of classes for all 
items in the user interface. 

To provide network access to appli¬ 
cations, NEWS supports a client-server 
model for applications development. 
The term client server has an unusual 
meaning here. The server is the local 
workstation at which the user’s display 
device resides (in other words, it’s a 
display server), and the client can be the 
remote system on which the actual ap¬ 
plication resides. This model allows the 
application to be partitioned into dis¬ 
tinct parts, which can be executed on 
different systems. The client applica¬ 
tion interchanges requests with the serv¬ 
er at the user’s display station. In gener¬ 
al, the client application (in SoundWorks 
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Figure 6. 
Example mix 
operation: 
source wave- 
sound window 
(a), modifier 
wave-sound 
window (b), and 
the results of the 
operation (c). 


(c) 


called the sound kernel ) deals with the 
actual application, while the server deals 
with user interface issues. 

To address the performance require¬ 
ments of interactive applications, NEWS 
allows application developers to speci¬ 
fy their own high-level network proto¬ 
col to communicate between the appli¬ 
cation-specific code and the user 
interface code. The client application 
downloads the PostScript user interface 
code to the server at startup. This code 
thus resides on the server and commu¬ 
nicates with the client application code 
using the network protocol defined by 
the application developer. 

System architecture. We used an ob¬ 
ject-oriented design approach to devel¬ 
op the high-level architecture for the 
SoundWorks system. First, we identi¬ 
fied the major components of the sys¬ 
tem and the interactions between them. 
Next, we partitioned the components 


for distribution across the network. Class 
specifications were developed for each 
component and successively refined into 
subclass specifications to produce the 
system implementation. 

SoundWorks’ major components can 
be derived from the system overview 
section. They are the windows that rep¬ 
resent sounds, lines, and operations; the 
sounds themselves; and operations on 
the sounds. These components can be 


partitioned into the local user-interface- 
specific code, which consists of the win¬ 
dows and other graphic items, and the 
remote application-specific code, which 
implements the sounds, lines, and oper¬ 
ations. 

In SoundWorks, the application-spe¬ 
cific code, or client application, imple¬ 
ments a sound kernel and manages 
sounds and lines, performs operations 
on sounds, and interfaces to digital hard¬ 
ware. The user interface, residing on 
the local system, creates and manages 
such items as windows, buttons, and 
sliders. When the user requests an oper¬ 
ation on a sound, the user interface 
communicates with the sound kernel to 
perform the operation. This communi¬ 
cation is completely defined by the pro¬ 
tocol between the user interface and the 
sound kernel. The protocol is imple¬ 
mented by a user interface module and 
a client application module resident on 
the server and client systems, respec¬ 
tively. The client application module 
receives requests from the user inter¬ 
face module and accesses the sound 
kernel through a well-defined interface. 
Figure 7 shows ajiigh-level representa- 
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| Sound | 

| Sound | 
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Figure 7. SoundWorks system architecture. 
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Flow-of-control example 


To demonstrate the roles of the objects and modules in the 
system, we present an example of scaling the amplitude of 
one sound by a line segment. The example includes the ob¬ 
jects that are created and the methods called to perform the 
operation. 

First, a FileSoundWindow must be created and a file sound 
loaded. To create a FileSoundWindow, the user chooses the 
create file sound menu command. The creation of the File¬ 
SoundWindow and the specification of the file sound are per¬ 
formed on the local system. When the user chooses the load 
button, the loadSound method first creates a FileSoundView, 
which in turn creates a new Sound object, one of the classes 
of the user interface module on the local system. The File¬ 
SoundWindow asks the view to load the sound by calling the 
loadSound method in the Sound object. The Sound object 
sends a loadFile request to the remote client application. The 
client application fields the request, performs file_create to 
create the file sound, and returns the result to the sound ob¬ 
ject, which returns to the FileSoundView and finally the File¬ 
SoundWindow. 

If the result is positive, the paint method is invoked to dis¬ 
play the file sound in the view. The view invokes the paint 
method in the Sound object to initiate the drawing process. 

On receiving the paint request, the client application calls the 
sound_paint routine in the sound kernel. The sound kernel 
draws the sound using the paint_window, ps_moveto, and 
psjineto routines provided by the client application. These 
routines send actual PostScript commands to the user inter¬ 


face to draw the sound. At this point, the sound is visible and 
can be accessed through the SoundView. 

The next steps are to create a LineSegmentWindow and to 
draw a line segment in it. The LineSegmentWindow is created 
using the create line menu command. When the user chooses 
the draw button, the draw method in the LineSegmentView is 
invoked. The local system handles the drawing of the line 
segments completely; there is no interaction with the remote 
sound kernel. The load operation in the LineSegmentWindow 
invokes the loadLine method in the LineSegmentView, which 
then calls loadLine in the Sound object. Just as with the file 
sound, the sound object interacts with the remote client appli¬ 
cation to create the line and draw it in the LineSegmentView. 

At this point, both the file sound and the line segments 
have been specified; only the scale operation itself needs to 
be performed. The user chooses the scale operation menu 
command, which creates a scale operation window. The scale 
operation window asks the user to choose the source sound 
to be scaled and the sound (in this case, line segment) to use 
to scale the sound. This is all done locally without any inter¬ 
action with the sound kernel. When the user hits the “doit” 
button, the scaleOperation in the operation object is invoked. 
This causes a message to be sent to the remote client appli¬ 
cation. The client application receives the message and calls 
the scale_operation routine provided by the sound kernel to 
perform the operation. The result of the scale operation is 
then returned to the operation object and in turn to the Scale- 
OperationWindow. 


tion of the system architecture. Subse¬ 
quent sections present the specifications 
of the user interface, the network pro¬ 
tocol, and the sound kernel. An exam¬ 
ple of the flow of control between the 
various components of the system ap¬ 
pears in the “Flow-of-control example” 
sidebar. 

User interface class specifications. The 

user interface creates and manages the 


graphic objects displayed at the user’s 
workstation. We grouped graphic ob¬ 
jects that share common features into 
high-level specifications and used these 
class specifications to develop subclass 
specifications for each object of the same 
type. Examples of objects that share 
common features are windows, compo¬ 
nents in the windows, and objects used 
to represent sounds. 

The class specifications for the user 


interface form a hierarchy based on the 
class inheritance. Figure 8 presents the 
inheritance hierarchy for the major class¬ 
es. At the highest level of the hierarchy 
are the predefined classes provided by 
NEWS, including Object, LiteWindow, 
LiteMenu, and Liteltem. We used the 
LiteWindow class specification to spec¬ 
ify the four types of windows supported 
by SoundWorks: control, operation, 
help, and sound. Other windows in 


I ScaleOperationWindowf - 

| StretchOperationWindow | - 


| LiteWindow | | Sound | | Operation | | Sounc 

IView | | LiteMenu | 

| Liteltem | 

ControlWindow | | Operatio 

nWindow | | HelpWindow | | SoundWindow | 

—| FileSoundView | | Sliderltem j- 

-J Textltem | 

MergeOperationWindow |— 

| FileSoundWindow |- 


—| WaveSoundView | | Buttonltem |- 

-j SoundScrall | 


Figure 8. SoundWorks class hierarchy. 
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Figure 9. SoundWorks client hierarchy for the FileSoundWindow class (a) and 
the MergeOperationWindow class (b). 


SoundWorks are defined as their sub¬ 
classes. 

One class can also be a client of an¬ 
other class. For example, a window is a 
client of objects like buttons and slid¬ 
ers, and SoundWindows are clients of 
other classes, including the SoundView 
class, which is used for displaying and 
manipulating the different types of 
sounds. Figure 9a gives the client hier¬ 
archy for the FileSoundWindow class, 
while Figure 9b shows the hierarchy for 
the MergeOperation Window class. The 
other classes have similar client hierar¬ 
chies. 

Predefined NEWS classes. At the root 
of all NEWS classes is the generic class 
Object (see Figure 8). It defines two 
methods: “new” and “doit.” The new 
method, which is called to create an 
instance of the class, is required by ev¬ 
ery class. The doit method is used to 
create temporary methods for internal 
purposes. 

NEWS provides a set of subclasses of 
the class Object that implement win¬ 
dows, menus, and other common items 
(for example, buttons and sliders). In 
SoundWorks we used these classes both 
as superclasses for defining new classes 
and for clients. Here, we briefly de¬ 
scribe the classes provided by NEWS. 
More details are available in the NEWS 
user’s manual. 6 

LiteWindow. This class provides a 
standard format for displaying and us¬ 
ing windows, and includes a set of con¬ 
trols and menus for manipulating such 
window features as size and position. 
LiteWindow defines methods for creat¬ 
ing, destroying, moving, and painting 
the window. For example, the paint 
method is used to paint or draw the 
window (and all graphic objects within 
it). 

LiteMenu. This class provides a stan¬ 
dard set of pull-right menus that can be 
associated with a window. A menu is 
defined as an array of <entry, value> 
pairs. The entry is the title that will 
appear in the menu, and the value is 
either a method to invoke or another 
menu. 

Liteltem. This class provides a set of 
standard graphic items that can be in¬ 
corporated into other classes. These 
items are defined as subclasses of class 
Liteltem and include items for entering 


text (Textltem), buttons (Buttonltem), 
sliders (Sliderltem), message areas 
(Messageltem), and choice items (Ar- 
rayltem). 

SoundWindow class specifications. 

This class defines the window used to 
access sound objects. A subclass of 
LiteWindow, it inherits the look and 
functions of that class. The SoundWin¬ 
dow is used as the superclass for a set of 
subclasses for each type of sound. The 
SoundWindow class overrides the meth¬ 
ods “new” and “paint,” as defined in 
LiteWindow, to include SoundWindow- 
specific code and to define sound-relat¬ 
ed methods common to all types of 
sounds. The methods loadSound, close- 
Sound, and infoSound, which are com¬ 
mon to all SoundWindows, are invoked 
when the user chooses the graphic item 
(for example, a button or slider) associ¬ 
ated with the item (see Figure 1). These 
methods support a 
basic interface to 
the sounds, allow¬ 
ing the SoundWin¬ 
dow to load, close, 
and retrieve in¬ 
formation about 
sounds, and play 
file sounds. 

The SoundWin¬ 
dow is a client of 
the SoundView 
class, which han¬ 
dles the actual dis¬ 
play and modifica¬ 
tion of sounds. 

(SoundView class¬ 
es are described in 
the later section 


entitled “SoundView class specifica¬ 
tion.”) SoundWindow methods that 
perform a sound-related operation usu¬ 
ally invoke a method in the SoundView 
class to perform the operation and to 
display the results. An advantage of this 
division between SoundWindow and 
SoundView is that any number of Sound- 
Views may be present in a SoundWin¬ 
dow, thus allowing the display of sound 
files with any number of tracks. 

The specifications we present pro¬ 
vide only an overview of the class spec¬ 
ification. (For instance, in some cases 
parameters are missing.) The interest¬ 
ed reader can find a complete listing of 
these specifications provided by Reich- 
bach. 10 

Figure 10 contains the definition of 
SoundWindow. Each subclass specifi¬ 
cation overrides the specification for 
several methods defined in the figure. 
The createltems method is modified to 


class: 

SoundWindow 

superclass: 

LiteWindow 

instance variables/methods: 

sndid 

: SoundWindow identifier 

sndview 

: instance of a SoundView 

createltems 

: method used to create items 

class methods: 


new(parent,id) : create an instance of SoundWindow 

paint 

: paint window and contents 

loadSound 

: load a sound 

closeSound 

: close a sound 

infoSound 

: get information about a sound 


Figure 10. Specification of SoundWindow. 
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class: 

FileSoundWindow 

superclass: 

SoundWindow 

instance variables/methods: 

filename 

: name of sound file 

start 

: default starting point in file 

duration 

: duration of sound 

createltems 

: create items specific to 
FileSoundWindow 

class methods: 

new(parent.id): create an instance of 
FileSoundWindow 

loadSound 

: load FileSound 

closeSound 

: close FileSound 

playSound 

: play FileSound 

saveSound 

: save FileSound 

undoSound 

: undo the last operation 


class: SoundView 

superclass: Object 

instance variables/methods: 

sndid 

: sound identifier 

height 

: height of SoundView 

width 

: width of SoundView 

leftedit 

: left edit marker 

rightedit 

: right edit marker 

sound 

: instance of Sound class 

scroll 

: instance of SoundScroll class 

createMenu 

: create menu specific to SoundView 

class methods: 


new(parent.id) 

: create an instance of SoundView 

paint 

: paint window (and contents) 

closeSound 

: close SoundView 

infoSound 

: get info about sound in SoundView 


Figure 11. Specification of FileSoundWindow. Figure 12. Specification of SoundView. 


class: FileSoundView 

superclass: SoundView 

instance methods: 

createMenu : create a FileSoundView menu, 
class methods: 

loadFileSound(sndid, filename, start, duration) 

: load a file 

saveSound(sndid,filename) : save FileSound 
playSound(sndid,filename) : play FileSound 
undoSound(sndid,filename): undo operation 
repeatOperation : repeat a section of 

sound 

deleteOperation : delete a section of 

sound 

scaleOperation : change the amplitude 

stretchOperation : change the length 

zoomOperation : magnify the view 

helpOperation : invoke on-line help 


Figure 13. Specification of FileSoundView. 


class: 

OperationWindow 

superclass: 

LiteWindow 

instance variables/methods: 

op 

: operation object 

opid 

: operation id 

soundl 

: source sound 

sound2 

: destination sound 

new? 

: create a new sound 

createltems 

: method to create items in window 

class methods: 

new(parent,id): create an instance of 
OperationWindow 

paint 

: paint operation window (and 
contents) 

doOperation 

: ask user to choose sounds or lines 
to operate on 

cancelOp 

: cancel an operation and reset 
variables 


Figure 14. Specification of OperationWindow. 


class: MergeOperationWindow 

superclass: OperationWindow 

class methods: 

doOperation : ask user for information, do merge 

Figure IS. Specification of the Merge operation. 


create subclass-specific items, such as 
text areas, sliders, and buttons. The new 
method is modified to create a Sound- 
View for each type of sound. The three 
subclasses of SoundWindow are File¬ 
SoundWindow, WaveSoundWindow, 
and LineWindow. These are used to 
access sounds stored on disk, access 
sounds represented as waveforms, and 
define line segments, respectively. 

FileSoundWindow. This subclass pro¬ 
vides access to sounds stored on disk. 
Before accessing a sound file, the user 


must specify the 
variables defining 
the file name, start¬ 
ing point, and du¬ 
ration. The File¬ 
SoundWindow 
overrides the cre- 
ateltems method 
to define sound- 
file-specific items 
for inputting the name of the sound file 
and the start and duration times. The 
loadSound method is modified to in¬ 
voke the sound-file-specific load meth¬ 


od. In addition, the saveSound, play- 
Sound, and undoSound methods are 
defined. The first one saves a sound file 
on the disk, the second plays a sound 
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file, and the third undoes an operation. 
The current version of Sound Works sup¬ 
ports only one level of undo: the last 
operation. 

The FileSoundWindow is defined in 
Figure 11. 

WaveSoundWindow. This subclass 
helps access sounds represented as sim¬ 
ple waveforms. There are five types of 
waveform sounds: sine, triangle, saw¬ 
tooth, square, and DSP. Wave sounds 
require that the frequency, amplitude, 
and duration be specified before the 
sound is loaded. This class specification 
defines the sine, sawtooth, and triangle 
wave sounds. The square wave sound 
and DSP sound are specified as sepa¬ 
rate subclasses because they require ad¬ 
ditional information. The WaveSound¬ 
Window supports only these basic 
waveforms because the underlying im¬ 
plementation of wave sounds is in soft¬ 
ware (which can be slow for long wave 
sounds). To obtain better performance, 
we intend to implement more complex 
wave sounds using the DSP SoundWin- 
dow. 

WaveSoundWindow classes are spec¬ 
ified in a manner similar to the File¬ 
SoundWindow and are not shown here. 
The class specification and more details 
are provided by Reichbach. 10 

LineWindow. This subclass helps de¬ 
fine line segments. It is similar to the 
FileSoundWindow and WaveSound¬ 
Window, containing methods and vari¬ 
ables to load, close, and get information 
about line segments. Due to space con¬ 
straints, it is not shown here. 

SoundView class specification. This 
specification defines the graphic repre¬ 
sentation and operations on sounds con¬ 
tained in the SoundWindow. Correspond¬ 
ing to the subclasses of SoundWindow, 
there are three subclasses for the Sound- 
View class: FileSoundView, WaveSound- 
View, and LineView. When a sound or 
line window is created, an instance of a 
subclass of SoundView is also created 
and assigned to the “sndview” variable 
for the sound or line window. Then, 
whenever the user requests an opera¬ 
tion defined in a window, a method in 
the SoundView class is invoked to per¬ 
form the operation. The instance vari¬ 
able “sound” refers to an instance of 
class Sound (which is presented in the 
later section entitled “User interface 
module”) and is used to perform sound- 


The object-oriented 
approach to the design of 
the user interface 
supported an incremental 
development. 


and line-segment-related operations. 
The local instance method createMenu 
is used to define the specific menu for 
each subclass. The SoundView class also 
creates an instance of class SoundScroll, 
which is used to scroll through the sound 
displayed in the SoundView. Figure 12 
shows the SoundView class definition. 

Like SoundWindows, each subclass 
of the SoundView class defines the menu 
and methods specific to the subclass. 
The menu includes both common oper¬ 
ations like zoom and help, and specific 
operations for each type of sound. In 
addition, each subclass defines a meth¬ 
od to load the correct type of sound (or 
line). For example, the FileSoundView 
class defines a method to load the file 
sound. The loadFileSound method is 
invoked by the loadSound method in 
the FileSoundWindow. The FileSound¬ 
View class also defines file-sound-spe¬ 
cific methods for playing the sound, sav¬ 
ing the sound, and undoing the last 
operation on the sound. Other subclass¬ 
es define their own menus and methods. 
For example, the LineView specifies a 
menu that includes common operations, 
such as zoom, edit, and help, and specif¬ 
ic operations such as drawing line seg¬ 
ments. 

Figure 13 shows the definition of the 
FileSoundView class. The WaveSound- 
View and LineView subclasses are de¬ 
fined similarly. 

OperationWindow class specifica¬ 
tions. These specifications define win¬ 
dows that can be used to perform oper¬ 
ations in which one sound or line 
modifies another sound. The operations 
accessed through these windows are 
merge, mix, scale, and stretch. Each 
uses the same command syntax and pa¬ 
rameters and requires the user to spec¬ 
ify the two sounds for the operation and 
whether a new sound window should be 
created. 

The mix operation adds two sounds 
together and produces the result. The 


merge operation inserts the destination 
sound into the source sound. The scale 
operation modifies the amplitude of the 
source sound using the destination (usu¬ 
ally a line segment). The stretch opera¬ 
tion, implemented using linear interpo¬ 
lation, is like a variable-speed playback, 
using the destination sound as a rate of 
change for the source sound. For exam¬ 
ple, if a constant-valued destination 
sound (say, a line segment of value 2) is 
used to stretch a source sound, the re¬ 
sult is a sound with double the pitch of 
the source sound and half the duration. 

Operation windows are based on a 
generic class called an OperationWin¬ 
dow, which specifies the format and 
usage of the operation. Operation- 
Windows are identified by a unique 
variable “opid,” which identifies each 
active operation. The Operation- 
Window creates an instance of the Op¬ 
eration object, “op,” which contains 
operation-specific methods. The Oper¬ 
ationWindow corresponding to each 
specific operation is defined as a sub¬ 
class of the class OperationWindow and 
invokes an operation-specific method 
in the Operation object. Figure 14 shows 
the specification for class Operation- 
Window. 

Each subclass of OperationWindow 
invokes an operation-specific version 
of the doOperation method. Figure 15 
shows the specification for the Merge 
operation; other subclasses are speci¬ 
fied in the same manner. The specifica¬ 
tion for the Operation class is presented 
in the later section entitled “User inter¬ 
face module.” 

Protocol specification 

The protocol defined between the user 
interface code and client application is 
partitioned into two modules. The user 
interface module defines an interface 
for each operation and sound support¬ 
ed by SoundWorks. The client applica¬ 
tion module receives requests from the 
user interface module, calls the sound 
kernel to perform the requests, and re¬ 
turns the results to the user interface. 

User interface module. This module 
is defined by two classes: Sound and 
Operation. The Sound class defines the 
message format for each sound-related 
request, while the Operation class de¬ 
fines the message format for each oper¬ 
ation. When a method in a Sound object 
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class: Sound 

superclass: Object 


class methods: 
new(parent,id) 
paint(sndid,height,width) 
closeSound(sndid) 
infoSound(sndid) 
saveSound(sndid,filename) 
playSound(sndid,filename) 
undoSound(sndid, filename) 
loadFile(sndid,filename,start,duration) 
load W ave(sndid,type ,freq,amp) 
loadLine(sndid,points) 

(a) 


create a sound object 
paint the sound 
close the sound 
get information 
save sound file 
play sound file 
undo operation 
load sound file 
load a wave sound 
load a line segment 


class: Operation 

superclass: Object 

class methods: 

new(parent,id) . crea t e an operation object 

mergeOperation(opid,soundl,sound2,new?): merge sounds/lines 
scaleOperation(opid,soundl,sound2,new?) : scale sounds/lines 
stretchOperation(opid,soundl,sound2,new?): stretch sounds/lines 
mixOperation(opid,soundl,sound2,new?) : mix two sounds/lines 
(b) 


Figure 16. Specifications of the Sound (a) and Operation (b) classes. 


Figure 17. Client 
application module. 


/* Client Application Module */ 
loop 

wait for request 
decode the request 
call sound kernel 

/* sound kernel calls routine to return result */ 
until user is done 


sys_message(string) 

display a system message for user 

error_message(cid,string) 

display a message in a window 

set_info(cid,size) 

return the size information 

return_result(cid, result) 

return a result 

return_result_string(cid,result,string) 

return a result and string 

paint_window(cid) 

start to draw a sound in window 

paint_icon(cid) 

start to draw a sound icon 

ps_moveto(x,y) 

move to (and set current position) x,y 

ps_lineto(x,y) 

draw a line from current position to 
x,y 


Figure 18. Routines provided by the client application module. 


or an Operation object is invoked, a 
message is sent to the client application 
module. After sending this request, the 
calling object waits for the result. Fig¬ 
ures 16a and 16b show the specifica¬ 


tions for the Sound and Operation 
classes. 

Client application module. This mod¬ 
ule provides the interface between the 


objects in the user interface and the 
sound kernel. As with other NEWS- 
based applications, the client applica¬ 
tion module is written in C and uses the 
libraries provided by NEWS to com¬ 
municate with the user interface code. 

As Figure 17 shows, the main func¬ 
tions of the client application module 
are to wait for a request from the user 
interface module, decode the request, 
and perform it by calling the sound 
kernel. 

The client application module also 
provides a set of routines called by the 
sound kernel to return the result of each 
request. These routines communicate 
with the user interface to return result 
values (with or without an accompany¬ 
ing text string, like an error message), to 
return size information, and to paint 
the graphic representation of the sound 
(or line). They provide access to the 
user interface and are independent of 
the application programming environ¬ 
ment. This allows other user interfaces, 
using possibly other application pro¬ 
gramming environments, to be inte¬ 
grated with the sound kernel in a 
straightforward manner. The integra¬ 
tion effort requires specifying the 
above routines, writing the client appli¬ 
cation module loop, and mapping user 
interface requests to the sound kernel 
interface. 

For example, to integrate the sound 
kernel with an X Windows-based appli¬ 
cation would require the X client appli¬ 
cation to call the sound kernel routines 
(defined in the next section) in response 
to user requests. In addition, the X Win¬ 
dows application would have to provide 
the client application routines that al¬ 
low the sound kernel to return the re¬ 
sult of the operation to the application. 
For example, the routine error_message 
would display a message for the user, 
while ps_moveto would map into the 
equivalent X routine to draw a line. 
Figure 18 lists the routines provided by 
the client application module for com¬ 
municating with the user interface. When 
the sound kernel finishes performing a 
request for the user, these routines re¬ 
turn the result. 

Sound kernel 
specification 

This kernel manages sounds and lines, 
performs operations on sounds, and in- 
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Figure 19. Sound- 
specific routines to 
create an internal 
sound structure 
(a) and operations 
to load sounds (b). 


sound_close(sndid) 

: close the sound 

sound_info(sndid) 

: return information about the sound 

sound_paint(sndid,height,width) 

: paint the sound 

sound_read(sndid, start, duration) 

: read samples from the sound 

sound_write(sndid,start,duration) 

: write samples to the sound 

sound_save(sndid,name) 

: save the sound 


Figure 20. Generic sound routines. 


merge_operation(id,soundl,sound2,newflag) 
scale_operation(id,soundl,sound2,newflag) 
stretch_operation(id,soundl,sound2,newflag) 
mix_operation(id,soundl,sound2,newflag) 

(a) 

delete_operation(id,soundl,left,right) : delete section of sound 

repeat_operation(id,soundl,left,right) : repeat section of sound 

(b) 

Figure 21. Routines to perform operations on sounds (a). Delete and repeat op¬ 
erations (b). 


merge 
change the amplitude 
change the duration 
mix two sounds 


file_create(sndid,info) : create a file sound 
wave_create(sndid,info) : create a wave sound 
line_create(sndid,info) : create a line sound 

(a) 

load_file(sndid,filename,start,duration) 
load_wave(sndid,type,frequency amplitude,duration, 
extra) 

load_line(sndid,points) 

(b) 


terfaces to the digital hardware. These 
functions implement the methods de¬ 
fined in the Sound and Operation class¬ 
es. In response to user requests, the 
client application module accesses the 
functions through the interface described 
in the next section. The sound kernel 
interface is independent of the client 
application module interface that ac¬ 
cesses it. The sound kernel accesses the 
routines supplied by the client applica¬ 
tion module to return the result of a 
request, report errors, and draw the 
graphic representation of a sound or 
line. 

Interface to sounds. The sound ker¬ 
nel manages three different types of 
sounds: sound files, wave sounds, and 
lines. Each sound provides a unique 
create routine used to create the sound, 
as well as generic sound routines com¬ 
mon to all sounds. Once a sound is cre¬ 
ated, it is accessed in the same manner 
regardless of its type. 

Sound-specific routines. The routines 
shown in Figure 19a create an internal 
structure for a sound of the specified 
type. The info parameter provides spe¬ 
cific information, such as the sample 
rate and sample size. Once created, a 
sound is loaded using a load operation 
(see Figure 19b) that inserts the re¬ 
quested sound into the previously 
created sound structure. For example, 
the load_file operation loads the sound 
file specified by filename, starting 
time, and duration into the sound struc¬ 
ture. The amount of sound that can be 
loaded is limited only by the size of the 
address space of the underlying com¬ 
puter. 

Generic sound routines. These rou¬ 
tines access the sound and are called in 
response to user requests. Currently, 
SoundWorks supports the sound_write 
and sound_save routines only for file 
sounds. The sound_write routine writes 
the specified portions of the sound, while 
the sound_save routine saves the entire 
sound on the sound file system. Figure 
20 shows the routines. 

Interface to operations. The sound 
kernel provides the routines shown in 
Figure 21a for each operation support¬ 
ed by SoundWorks. The operations ac¬ 
cess the sounds through the interface 
defined in the previous section and re¬ 
turn operation results by using the rou¬ 


tines supplied by the client application 
module. The parameter id indicates the 
operation window that requested the 
operation. The parameters soundl and 
sound2 identify the source and destina¬ 
tion sounds. If the parameter newflag is 
set, then a new file sound is created as a 
result of the operation. 

FileSounds also have the two opera¬ 
tions shown in Figure 21b to delete and 
repeat sections of sound. The left and 
right parameters delimit the section of 
sound to operate on. 

Interface to digital hardware. The 

sound kernel is also responsible for in¬ 
terfacing with the digital hardware: the 
sound file system, play/record devices, 
and the DSP hardware. 

The interface to the sound file system 


depends on which system is used. Sound- 
Works was designed using the CARL 
(Computer Audio Research Laborato¬ 
ry) sound file system developed for 
Unix. 1 To access the sound files and to 
play or record them, SoundWorks re¬ 
lies on the libraries and commands pro¬ 
vided by the system. Commands are 
specified either in the user’s environ¬ 
ment or in a SoundWorks configura¬ 
tion file. 

In addition, SoundWorks provides 
access to the AT&T VMEbus DSP32 
signal-processing module. 11 This allows 
the user to integrate digital signal 
processing programs into the Sound- 
Works environment in a straightfor¬ 
ward manner. Using this interface 
requires knowledge of the DSP32 
module and the interface between the 
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DSP programs and internal sound data 
structures. 

Achievements 

We developed a working implemen¬ 
tation of SoundWorks that runs on our 
network of Sun workstations. Sound- 
Works is also installed at the Music 
Department’s Center for Computer 
Music Composition, where the sound 
kernel is resident on a Digital Equip¬ 
ment Corp. VAX 11/750 and a Digital 
Sound Corporation digital-analog con¬ 
verter, with a Sun computer serving as 
the graphics workstation. A third in¬ 
stallation, in the Electrical and Com¬ 
puter Engineering Department’s Com¬ 
munications Research Lab, is based 
completely on Sun workstations and 
includes an AT&T VMEbus DSP32 
signal-processing module. 

We achieved both goals set for the 
SoundWorks system: sound manipula¬ 
tion features and a flexible server-based 
system. The system provides all of the 
sound manipulation and creation fea¬ 
tures presented in the “System over¬ 
view” section except the DSP window. 
Integrating the user interface with the 
sound kernel demonstrated the viabili¬ 
ty of the server-based architecture. 

Experience with NEWS. The devel¬ 
opment of SoundWorks gave us first¬ 
hand experience in using the NEWS 
application programming environment 
and the object-oriented version of Post¬ 
Script. The object-oriented approach to 
the design and implementation of the 
user interface supported an incremen¬ 
tal development of the system. This let 
us develop and refine components in a 
structured manner. 

The support for distributed applica¬ 
tions was particularly useful. The divi¬ 
sion of the user interface and the applica¬ 
tion code made design and development 
easier because we could develop each 
section independently. 

Problems encountered with using 
NEWS fall into two categories: difficul¬ 
ties with the object-oriented version of 
PostScript and problems with NEWS 
itself. PostScript, while very good at 
graphics, is not a well-structured pro¬ 
gramming language. For example, all 
parameters are passed on the stack and 
there is no explicit checking for the 
number of parameters passed or for 
their type. And because NEWS was a 


An on-line help facility 
provides information 
on every sound and 
operation. 


new product, it had its own set of bugs 
and problems. 

Experience with SoundWorks. Sound- 
Works provides a user-friendly inter¬ 
face for manipulating sounds. Because 
the graphic interface supports a consis¬ 
tent user interaction regardless of the 
type of sound, learning to use Sound- 
Works is easy. In addition, the on-line 
help facility provides information on 
every supported sound and operation. 

Some problems did arise from the 
lack of accuracy in performing certain 
editing operations. In particular, op¬ 
erations that involve a small number of 
samples are difficult to perform be¬ 
cause the graphic representations are 
not accurate enough. Of course, the user 
can zoom a sound to the necessary level 
of detail, but this requires extra com¬ 
mands. 

There are also minor annoyances in 
the user interface code. These are main¬ 
ly in the interface defined for choosing 
the sounds and sections of sound when 
using operation windows. Currently, the 
operation window fixes the order of 
sound choice and does not tolerate user 
error. A mistake forces the user to re¬ 
start the operation. In addition, when 
all parameters have been input and the 
operation is started, it is impossible to 
halt the operation before completion. 
A related issue is the lack of support for 
grouping operations together so that 
the user can specify common operation 
sequences by using a macro language. 

In addition, drawing performance for 
large sounds needs to be addressed. For 
example, on a Sun-3 it takes approxi¬ 
mately 5 seconds per minute of sound to 
compute and display the graphic repre¬ 
sentation of the sound. Almost all of the 
time required to display a sound is tak¬ 
en up in two tasks: computing the bit¬ 
map representing the sound and the 
actual graphics operations themselves. 
One method to reduce the time needed 
for producing bitmaps is to generate 


intermediary bitmaps. This reduces the 
amount of data processed to generate 
the required bitmap. Also, to reduce 
the network overhead of drawing the 
bitmap, it is possible to compress the 
amount of data transferred over the 
network, thereby increasing perfor¬ 
mance. 


T he SoundWorks system provides 
a good starting point for future 
work. Two possible directions 
are the integration of new applications 
and the distribution of the sound kernel 
architecture. For example, it would be 
desirable to have different users, possi¬ 
bly running different applications, ac¬ 
cessing the sound kernel concurrently. 
Distributing the sound kernel would 
allow users to access audio devices and 
sound files residing on other worksta¬ 
tions. An approach we are considering 
for accessing the audio devices at an¬ 
other workstation is the integration of 
the sound kernel with a Vox server. 9 We 
could also distribute the sound file sys¬ 
tem itself on different machines. 

Another promising area for further 
research is the adoption of a sound file 
system that supports nondestructive 
editing to the SoundWorks kernel. This 
type of editing lets users “modify” sounds 
without actually modifying them. For 
example, an insertion is accomplished 
by adjusting pointers to the sound, not 
by changing the sound itself. 

It would also be desirable to port 
SoundWorks to other architectures. One 
candidate is the Next computer, which 
has integrated digital audio hardware. 
However, because the Next computer’s 
window system is not distributed, addi¬ 
tional work would be required to devel¬ 
op a network interface between the user 
interface and the sound kernel. ■ 
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Mediators in the 
Architecture of Future 
Information Systems 


Gio Wiederhold, Stanford University 


C | omputer-based information systems, connected to worldwide high-speed 
I networks, provide increasingly rapid access to a wide variety of data 

____J resources. 1 This technology expands access to data, requiring capabilities 

for assimilation and analysis that greatly exceed what we now have in hand. 
Without intelligent processing, these advances will provide only a minor benefit to 
the user at a decision-making level. That brave user will be swamped with ill- 
defined data of unknown origin. 


Mediators embody the 
administrative and 
technical knowledge 
to create information 
needed for user 
decision-making 
modules. The goal is 
to exploit the data 
technology puts within 
our reach. 


The problems. This article will expand on the two types of problems that exist: 

• For single databases, a primary hindrance for end-user access is the volume of 
data that is becoming available, the lack of abstraction, and the need to understand 
the representation of the data. 

• When information is combined from multiple databases, the major concern is 
the mismatch encountered in information representation and structure. 

Volume and abstraction. The volume of data can be reduced by selection. It is not 
coincidental that Select is the principal operation of relational database manage¬ 
ment systems, but selected data is still at too fine a level of detail to be useful for 
decision making. Further reduction is achieved by abstracting data to higher levels. 
Aggregation operations such as Count, Average, Standard_Deviation, Maximum, 
and Minimum provide some computational facilities for abstraction. Today, such 
abstractions are formulated within the end user’s application, using a variety of 
domain knowledge. 

For most base data, more than one abstraction must be supported: For the sales 
manager, the aggregation is by sales region, while aggregation by customer income 
is appropriate for marketing. Figure 1 presents examples of required abstraction 
types. 

Computations for abstraction may be extensive and complex. Collecting all 
instances that lead to an abstraction can involve recursion, say, locating all 
potentially useful flight segments for a trip. Such a computation cannot be 
specified with current database query languages. Hence, application programs are 
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Type of Abstraction 

Example 

Base Data Abstraction 

Granularity 

Sales detail 


Product summaries 

Generalization 

Product data 

-> 

Product type 

Temporal 

Daily sales 

-* 

Seasonally adjusted 
monthly sales 

Relative 

Product cost 

-» 

Inflation-adjusted trends 

Exception recognition 

Accounting detail 

-» 

Evidence of fraud 

Path computation 

Airline schedules 


Trip duration and cost 


Figure 1. Abstraction functions. 


written by specialists to reduce the data. 
Using specific data-processing programs 
as intermediaries reduces flexibility and 
responsiveness for the end user. The 
knowledge that creates the abstractions 
is hidden and hard to share and reuse. 

Mismatch. As Figure 2 shows, data 
obtained from remote and autonomous 
sources often will not match in terms of 
name, scope, granularity of abstractions, 
temporal units, and domain definitions. 
The differences shown in the examples 
must be resolved before automatic pro¬ 
cessing can join these values. 

Without an extended processing par¬ 
adigm, as proposed here, the informa¬ 
tion needed to initiate actions will be 
hidden in ever larger volumes of detail, 
scrollable on ever larger screens, in ever 
smaller fonts. In essence, the gap be¬ 
tween information and data will be even 
wider than it is now. Knowing that in¬ 
formation exists and is accessible gives 
end users expectations. Finding that it 
is not available in a useful form or that 
it cannot be combined with other data 
creates confusion and frustration. I be¬ 
lieve the reason some users object to 
computer-based systems, saying they 
create information overload, is that they 
get too much of the wrong kind of data. 
(See the sidebar, “Knowledge versus 
, data.”) 

Use of a model. To visualize the re¬ 
quirements we will place on future in¬ 
formation systems, let’s consider the 
activities carried out today when deci¬ 


Knowledge versus data 

I favor a pragmatic distinction be¬ 
tween data and knowledge in this 
model. 

• Data describes specific instanc¬ 
es and events. It may be gathered 
automatically or clerically. The cor¬ 
rectness of data can be checked 
versus the real world. 

• Knowledge describes abstract 
classes. Each class can cover 
many instances. Experts are need¬ 
ed to gather and formalize knowl¬ 
edge. 

One item of knowledge can affect 
the use of many items of data; also, 
one item of new data can disprove 
or weaken existing knowledge. 2 


sions are being made. Making informed 
decisions requires applying a variety of 
knowledge to information about the state 
of the world. 

To manage this variety, we employ 
specialists. To manage the volume of 
data, we segment our databases. In these 
partitions, partial results are produced, 
abstracted, and filtered. The problem 
of making decisions is now reduced to 
the issue of choosing and evaluating the 
significance of the pieces of informa¬ 
tion derived in those partitions and fus¬ 
ing the important portions. 

For example, an investment decision 
for a manufacturer will depend on the 
fusion of information on its own pro¬ 
duction capability versus that of others, 
its sales experience in related products, 
the market for the conceived product at 
a certain price, the cost-to-price ratio 


Type of Mismatch 


Example 

Domains 

Key difference 

Alan Turing: The Enigma 

Reference for reader 

versus 

QA29.T8H63 

Reference for librarian 

Scope difference 

Employees paid 

Includes retirees 

versus 

Employees available 

Includes consultants 

Abstraction grain 

Personal income 

From employment 

versus 

Family income 

For taxation, housing 

Temporal basis 

Monthly budget 

Central office 

versus 

Weekly production 

Factory records 

Domain semantics 

Postal codes 

One can cover multiple places 

versus 

Town names 

Can have multiple codes 

Value semantics 

Excessive_pay 

Per Internal Revenue Service 

versus 

Excessive_pay 

Per board of directors 


Figure 2. Mismatches in data resources. 
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appropriate for the size of the market, 
and the cost of the funds to be invested. 
Specialists would consider these diverse 
topics and consult multiple data resourc¬ 
es to support their claims. The decision¬ 
maker will integrate and fuse that infor¬ 
mation to arrive at a single set of ranked 
alternatives, considering risk and long- 
range objectives in combining the re¬ 
sults. 

An effective architecture for future 
information systems must support au¬ 
tomated information-acquisition pro¬ 
cesses for decision-making activities. By 
default, I model the solution following 
the partitioning seen in human-based 
support systems. However, most aspects 
of human behavior cannot be captured 
and formalized adequately. We merely 
define a modular architecture wholly 
composed of pieces of software that are 
available or appear to be attainable in a 
modest time frame, say 10 years. Mod¬ 
ern hardware should be capable of deal¬ 
ing with the processing demands im¬ 
posed by such software. 

Current state. We are not starting 
from a zero base. Systems are now be¬ 
coming available that are capable of 
achieving what Vannevar Bush envis¬ 
aged nearly a half-century ago for his 
information management desk 
(Memex). 3 We can select and scroll in¬ 
formation on our workstation displays. 
We have access to remote data and can 
present the values in one of multiple 
windows. We can insert documents into 
files in our workstation, and we can 
annotate text and graphics. We can reach 
conclusions based on this evidence and 
advise others of decisions made. 

The vision in this article is intended 
to provide a basis for automated inte¬ 
gration of such information. Neither 
Memex nor our current systems address 
that level of processing. At best, they 
provide graphic visualizations so that 
voluminous information is assimilated 
more easily by the end user. 

A model of information 
processing 

Information lets us choose among sev¬ 
eral otherwise indistinguishable actions. 
Let’s again consider a simple business 
environment. Say a factory manager 
needs sales data to set production lev¬ 
els, a sales manager needs demographic 


information to project future sales, and 
a customer wants price and quality in¬ 
formation to make purchase choices. 

Most of the information these people 
need can be represented by factual data 
and is available on some computer. 
Communication networks can make the 
data available wherever needed. How¬ 
ever, before decisions are made, a con¬ 
siderable amount of knowledge also has 
to be applied. Today, most knowledge 
is available through various administra¬ 
tive and technical staff at institutions. 4 
Some knowledge is encoded in data- 
processing programs and expert systems 
for automated processing. 

Use of supporting information for 
decision making is similar in partially 
automated and manual systems. In man¬ 
ual systems, the decision-maker obtains 
assistance from staff and colleagues who 
peruse files and prepare summaries and 
other documentation. With partial au¬ 
tomation, the staff uses computers to 
prepare these documents. The decision¬ 
maker rarely uses the computer, be¬ 
cause the information from multiple 
sources is too diverse for automatic in¬ 
tegration. 

Processing and applying knowledge. 

A technician will know how to select 
and transfer data from a remote com¬ 
puter to one used for analysis. A data 
analyst will understand the attributes of 
the data and define the functions to 
combine and integrate the data. A stat¬ 
istician might provide procedures to 
aggregate data on customers into groups 
that present distinctive behavior pat¬ 
terns. A psychologist might provide clas¬ 
sification parameters that characterize 
the groups. 

Ultimately, it’s up to a manager to 
assess the validity of the classifications 
that are made, use the information to 
make a decision, and assume the risk of 
making the decision. A public relations 
person might take the information and 
present it to stockholders, the people 
who eventually assume the risk. Since 
these tasks are characterized by data 
and knowledge gathered in the past and 
projected into the future, we term these 
tasks planning. (This definition of plan¬ 
ning is more extensive than that used in 
artificial intelligence research, 5 although 
the objectives are the same.) 

To be able to deal with support for 
planning in a focused way, we model the 
information-processing aspects. Figure 
3 illustrates the two distinct feedback 


loops and their interaction. The data 
loop closes when the effects of actions 
taken are recorded in the database. The 
knowledge loop closes when recently 
gained knowledge is made available so 
it can be used for further selection and 
data-reduction decisions. At their in¬ 
teraction points, information is created. 
Those points are of prime concern for 
future systems. 

Creation of information. The model 
in Figure 3 identifies the interaction 
points where, during processing, infor¬ 
mation is created. Since getting infor¬ 
mation means that something novel has 
been learned, one or more of the fol¬ 
lowing conditions have to hold: 

• The information is obtained from a 
remote source that was previously not 
known locally (Step 3.ii.b of Figure 3). 
Here, the information system must pro¬ 
vide communication and remote access 
support. A special case of this condition 
occurs when a database is used for re¬ 
call, to provide data we knew once but 
cannot remember with certainty. The 
database component is used here to 
communicate over time—from the past 
to the present. 

•Two previously distinct facts are 
merged or unified (Step 3.ii.c). A clas¬ 
sic, although trivial, example is finding 
one’s grandfather via transitivity of par¬ 
ents. In realistic systems, unification of 
data also involves computation of func¬ 
tions, say, the average income and its 
variation among groups of consumers. 

• Multiple results are fused using prag¬ 
matic assessments of the quality and 
risks associated within Step 4. Here, 
derived abstractions, rather than facts, 
are combined; the processing techniques 
are those associated with symbolic pro¬ 
cessing in rule-based expert systems, 
although they are also found coded with¬ 
in application programs. In our exam¬ 
ple, the market specialist might want to 
unify incomes of current consumers with 
their reading habits to devise an adver¬ 
tising strategy. 

Databases record detailed data for 
each of many instances or events. Re¬ 
ducing this detail to a few abstract cases 
increases the information content per 
element. Of these abstractions, only a 
small, manageable number of justified 
results is brought to the decision-mak¬ 
er. For instance, the market analyst has 
made it possible to base decisions on 
consumer groups rather than individual 
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consumers. Certain groups may be un¬ 
likely purchasers and are therefore not 
targeted for promotions. 

While the behavior of any individual 
may not adhere to the rules hypothe¬ 
sized in the prior steps, the expected 
behavior of the aggregate population 
should be close to the prediction. Fail¬ 
ures only occur if the underlying data 
contains many errors or if we have seri¬ 
ous errors in our knowledge. Uncer¬ 
tainty, however, is common. 

Uncertainty. We cannot predict the 
future with certainty. For automation 
of full-scale information systems, the 
processing of uncertainty measures must 
be supported, although subtasks do ex¬ 
ist whereby results can be precisely de¬ 
fined. Uncertainties within a domain 
may be captured by a formal model. 

The uncertainty of the results of an 
application is based on the uncertain 
precision of source information and the 
uncertainty created at each step where 
information is merged. For example, we 
collect domain-specific observations 
based on some criterion — say, people 
living in a certain postal-code area. We 
' also have data to associate an income 
level with that postal-code area. At the 
same time, we might know the income 
distribution of people buying some prod¬ 
uct. 

The desired result requires unifica¬ 
tion of the postal code with income to 
estimate potential sales. Unfortunate¬ 
ly, there is no logical reason why such a 
unification should be correct. We have 
some formal classes — namely, people 
with a certain postal code — and some 
other formalizable classes based on in¬ 
come. In addition, some natural classes 
exist that are not formalized but are 
intuitively known. In our example, these 
comprise the potential purchasers, of 
which there are several subgroups — 
including those found in the database 
who bought in the past and those who 
may buy the planned products in the 
future. For the future class, only infor¬ 
mal criteria can be formulated. 

The marketing manager will use de¬ 
finable classes — by postal code and by 
observed and recorded purchasing pat¬ 
terns —to establish candidate members 
for the natural class of potential con¬ 
sumers. These classes overlap; the more 
they overlap the more correct the deci¬ 
sion-maker’s predictions will be. If we 
infer from classes that do not match 
well, the uncertainty attached to the 


generated plans will be greater. But un¬ 
certainty is the essence of decision mak¬ 
ing and is reflected in the risk that the 
manager takes on. If we only have to 
report the postal codes for our consum¬ 
ers, we do not need a manager with 


decision-making skills or intelligent sup¬ 
port software. Hence, uncertainty is cre¬ 
ated when formal and natural classes 
are matched. 

Communication of knowledge and 
data is necessary to achieve this conflu- 



Major steps in the information-processing loops include: 

1. Data are made available. These are either factual observations or 
results from prior processing, or combinations thereof. 

2. Knowledge is made available. It derives from formal training and 
experience. 

3. Knowledge about the data and its content is applied: 

i Validation: Errors in data or knowledge are identified. 

ii Selection: Subsets of available data are (a) defined, (b) obtained, 
and (c) merged. 

iii Reduction: The data found are summarized to an appropriate 
level of abstraction. 

4. Results are made available and multiple results are fused. 

5. The combined information is utilized in two ways: 

i Actions are taken that will affect the state of the world. 

ii Unexpected results will augment the experience base of the 
participants and of others who receive this information, increasing 
their knowledge. 

6. The process loops are closed with two independent steps. 

i The actions and their effect are observed and recorded in some 
database. 

ii The knowledge is recorded to effect subsequent validation, data 
definition, selection, reduction, or fusion. 


Figure 3. Knowledge and data feedback loops and their interaction. 
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A manual approach 
to mediation 


The concept of mediation is re¬ 
lated to the notion of having cor¬ 
porate information centers, as 
promoted by IBM and others. 
These corporate resources are 
staffed and equipped with tools to 
aid any user needing information. 
The needs and capabilities of an 
information center, however, dif¬ 
fer from those of automated medi¬ 
ators: 

1. A single center, or mediator 
for that matter, cannot deal with 
the variety of information that is 
useful for corporate decision mak¬ 
ing. 

2. Automation of the function 
will be necessary to achieve ac¬ 
ceptable response time and 
growth of knowledge and its qual¬ 
ity over time. 

3. The user should not be bur¬ 
dened with the task of seeking 
out information sources. This 
task, especially if it is repetitive, is 
best left to an interaction of appli¬ 
cation programs in a workstation 
and automated mediation pro¬ 
grams. 

The information center notion 
initiates yet another self-serving 
bureaucracy within a corporation. 
Effective staff is not likely to be 
content in the internal service 
roles that an information center 
provides, so that turnover of staff 
and its knowledge will be high. 

The only role foreseen in such a 
center is mediation — bringing to¬ 
gether potential users with candi¬ 
date information. 

To manage mediation, modular¬ 
ization instead of centralization 
seems to be essential. Modularity 
is naturally supported by a distrib¬ 
uted environment, the dominant 
computing environment in the 
near future. 

Further reading 

Atre, S., Information Center: Strategies 
and Case Studies, Vol. 1, Atre Int’l 
Consultants, Rye, N.Y., 1986. 

Wetherbe, J.C., and R.L. Leitheiser, 
“Information Centers: A Survey of Ser¬ 
vices, Decisions, Problems, and Suc¬ 
cesses,” Information Systems Manage¬ 
ment, Vol. 2, No. 3, 1985, pp. 3-10. 


ence. The communication may occur 
over space or over time. The informa¬ 
tion systems we consider must support 
both communication and fusion of data 
and knowledge. 

Change. Our systems must also be 
able to deal with continuing change. 
Both data and knowledge change over 
time because the world changes and 
because we learn things about our world. 
Rules that were once valid eventually 
become riddled with exceptions, and 
the specialist who does not adapt finds 
that his or her work loses value. An 
information system architecture must 
deal explicitly with knowledge mainte¬ 
nance. (See the sidebar entitled “A 
manual approach to mediation.”) 

Information system 
components 

The components available today for 
building information systems are posi¬ 
tioned along a data highway provided 
by modern communication technology. 
The interaction of the components will 
be primarily constrained by logical and 
informational limitations, not by physi¬ 
cal linkages. When we place the compo¬ 
nents into the conceptual architecture, 
we will recognize lacunae, that is, places 
where there are no existing components, 
only inadequate or uncooperative ones. 
We will see where the components must 
work together. Effective systems can be 
achieved only if the data and knowl¬ 
edge interfaces of the components are 
such that cooperation is feasible. 

Data and knowledge resources. There 
is a wide variety of data resources. We 
might classify them by how close they 
are to the source. Raw data obtained 
from sensors, such as purchase records 
from point-of-sale scanners, or, on a 
different scale, images recorded by earth 
satellites, are at the factual extreme. 
Census and stock reports contain data 
that have gone through some process¬ 
ing, but they will be seen as facts by 
most users. 

At the other extreme are textual rep¬ 
resentations of knowledge. In general, 
books, research reports, and library 
material contain accumulated knowl¬ 
edge, contributed by writers and their 
colleagues. Unfortunately, from our 
processing-oriented viewpoint, that 


knowledge is difficult to integrate and 
fuse. For instance, combining a travel 
guide description with airline and bus 
schedules to plan a trip is a research 
challenge. The tables, maps, and figures 
in such documents are data as well, but 
rarely in a form that can be processed 
without human input. 

Workstation applications. The new 

generations of capable workstations 
provide the systems environment for 
planning activities. For planning, users 
need to interact with their own hypoth¬ 
eses, save intermediate results for com¬ 
parison of effects, and display alternate 
projections over time. This interaction 
with information establishes the insights 
you need to gain confidence in your 
decisions. 

Our architecture must not constrain 
the users as they exercise creativity at 
the workstation. A variety of data re¬ 
sources will be needed for planning pro¬ 
cesses. But help is needed to deal with 
the aggregation and mismatch problems 
being encountered. By providing com¬ 
prehensive support for access to infor¬ 
mation, the complexity of the end user’s 
applications can be reduced to such an 
extent that quite involved analyses re¬ 
main manageable. 

Network interfaces. Modern operat¬ 
ing and network systems simplify the 
users’ administrative tasks by handling 
all hardware resources and interfaces. 
Interfaces for remote access from the 
users’ workstation nodes to the nodes 
containing database servers are based 
on communication protocols and for¬ 
mats. They ignore the contents of the 
messages. Mediators, on their network 
nodes, will provide services that deal 
with the content of the data being trans¬ 
mitted. Mediators can be interposed 
using existing communication network 
protocols. 

The mediator 
architecture 

Intelligent and active use of informa¬ 
tion requires a class of software mod¬ 
ules that mediate between the worksta¬ 
tion applications and the databases. 
Mediation simplifies, abstracts, reduc¬ 
es, merges, and explains data. The ex¬ 
amples of mediation shown in the “Me¬ 
diation” sidebar are specialized and are 
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Mediation 


In this article, the term mediation covers a wide variety of 
functions that enhance stored data prior to their use in an 
application. Mediation makes an interface intelligent by deal¬ 
ing with representation and abstraction problems that you 
must face when trying to use today’s data and knowledge re¬ 
sources. 

Mediators have an active role. They contain knowledge 
structures to drive transformations. Mediators may store inter¬ 
mediate results. 

Some examples of mediation found in current information 
systems are shown here. Most readers will be able to add en¬ 
tries from their experience. 

• Transformation and subsetting of databases using view 
definitions and object templates. These techniques reorganize 
base data into new configurations appropriate to specific us¬ 
ers and applications. 

Barsalou, T., R.M. Chavez, and G. Wiederhold, “Hypertext Inter¬ 
faces for Decision-Support Systems: A Case Study,” Proc. Medinfo 
89, IFIP, 1989, pp. 126-130. 

Basu, A., “Knowledge Views in Multiuser Knowledge-Based Sys¬ 
tems,” Proc. Fourth IEEE Int’l Data Eng. Conf., IEEE CS Press, 

Los Alamitos, Calif., Order No. 827 (microfiche only), 1988, pp. 
346-353. 

Chamberlin, D.D., J.N. Gray, and I.L. Traiger, “Views, Authoriza¬ 
tion, and Locking in a Relational Data Base System,” Proc. 1975 
Nat’l Computer Conf., Vol. 44, AFIPS Press, pp. 425-430. 

Lai, K-Y., T.W. Malone, and K-C. Yu, “Object Lens: A Spreadsheet 
for Cooperative Work," ACM Trans. Office Information Systems, 
Vol. 6, No. 4, Oct. 1988, pp. 332-353. 

Wiederhold, G., “Views, Objects, and Databases," Computer, Vol. 
19, No. 12, Dec. 1986, pp. 37-44. 

• Methods to gather an appropriate amount of data. Con¬ 
ventional database management systems do not deal well with 
data that are recursively linked. To gather all instances, com¬ 
putations to achieve closure may process data from a relation¬ 
al database, as in some logic and database projects. To select 
sufficient instances for a narrowly phrased query, it is possible 
to broaden a search by generalization. A frequent abstraction 
is to derive temporal interval representations from detailed 
event data. 


Chaudhuri, S., "Generalization and a Framework for Query Modifi¬ 
cation,” Sixth IEEE Int’l Data Eng. Conf., IEEE CS Press, Los 
Alamitos, Calif., Order No. 2025, 1990, pp. 139-145. 

Ullman, J.D., Principles of Database and Knowledge-Base Sys¬ 
tems, Vol. II, Computer Science Press, 1989. 

Wiederhold, G., S. Jajodia, and W. Litwin: “Dealing with Granulari¬ 
ty of Time in Temporal Databases,” Lecture Notes in Computer 
Science, Vol. 498, R. Anderson et al., eds., Springer-Verlag, N.Y., 
1991, pp. 124-140. 

• Methods to access and merge data from multiple databas¬ 
es. These have to compensate for mismatch at the level of da¬ 
tabase systems, database structure, and the representation 
and meaning of the actual data values. Mismatch is often due 
to differing temporal representations, say, monthly budgets 
and weekly production figures. These methods may induce 
uncertainty in the results because of mismatched sources. 

Chiang, T.C., and G.R. Rose, “Design and Implementation of a 
Production Database Management System (DBM-2),” Bell System 
Technical J„ Vol. 61, No. 9, Nov. 1982, pp. 2,511-2,528. 

Dayal, U., and H.Y. Hwang, “View Definition and Generalization 
for Database Integration in Multibase: A System for Heteroge¬ 
neous Databases,” IEEE Trans. Software Eng., Vol. SE-10, No. 6, 
Nov. 1983, pp. 628-645. 


DeMichiel, L., “Performing Operations Over Mismatched Do¬ 
mains," IEEE Trans. Knowledge and Data Eng., Vol. 1, No. 4, 
Dec. 1989, pp. 485-493. 

Litwin, W., and A. Abdellatif: “Multidatabase Interoperability,” 
Computer, Vol. 19, No. 12, Dec. 1986, pp. 10-18. 

Sacca, D., et al., “Description of the Overall Architecture of the 
KIWI System,” ESPRIT 85, EEC, Elsevier, 1986, pp. 685-700. 

• Computations that support abstraction and generalization 
over underlying data. These are needed to bring data at a 
low level of detail to a higher level. Typical operations in¬ 
volve statistical summarization and searching for exceptions. 
Abstractions are also needed to resolve mismatches. 

Adiba, M.E., “Derived Relations: A Unified Mechanism for Views, 
Snapshots, and Distributed Data,” Proc. Seventh Conf. Very 
Large Data Bases, C. Zaniolo and C. Delobel, eds., IEEE Com¬ 
puter Soc. Press, Los Alamitos, Calif., Order No. 371 (microfiche 
only), 1981, pp. 293-305. 

Chen, M.C., and L. McNamee, “A Data Model and Access Meth¬ 
od for Summary Data Management,” Fifth IEEE Int’l Data Eng. 
Conf., IEEE CS Press, Los Alamitos, Calif., Order No. 1915, 
1989, pp. 242-249. 

DeZegher-Geets, I., et al., “Summarization and Display of On¬ 
line Medical Records,” M.D. Computing, Vol. 5, No. 3, Mar. 

1988, pp. 38-46. 

Ozsoyoglu, Z.M., and G. Ozsoyoglu, “Summary-Table-By-Exam- 
ple: A Database Query Language for Manipulating Summary 
Data,” First IEEE Int’l Data Eng. Conf., IEEE CS Press, Los 
Alamitos, Calif., Order No. 533 (microfiche only), 1984, pp. 193- 
202. 

• Much information is available in the form of text. Most 
text processing is limited today to selection and presentation. 
More can be done. Most routine reports tend to have a de¬ 
gree of structure that makes some analysis feasible. Devel¬ 
oping standards for text representation will help, regularizing 
textual information for further processing and mediation. 


Callahan, M.V., and P.F. Rusch, “Online Implementation of the 
Chemical Abstract Search File and the Chemical Abstracts Ser¬ 
vice Registry Nomenclature File,” Online Rev., Vol. 5, No. 5, 
Oct. 1981, pp. 377-393. 

McCune, B.P., et al., “Rubric: A System for Rule-Based Informa¬ 
tion Retrieval, “IEEE Trans. Software Eng., Vol. SE-11, No. 9, 
Sept. 1985, pp. 939-945. 

Sager, N., et al., Medical Language Processing, Computer Man¬ 
agement of Narrative Data, Addison-Wesley, Reading, Mass., 
1987. 


• Mediators may maintain derived data for the sake of effi¬ 
ciency. Having derived data reduces the need to access da¬ 
tabases, but the intermediate knowledge has to be main¬ 
tained. Research into truth-maintenance is relevant here. 
There is also a problem of maintaining integrity under con¬ 
current use. 

Filman, R.E., “Reasoning with Worlds and Truth Maintenance in 
a Knowledge-Based Programming Environment,” Comm. ACM, 
Vol. 31, No. 4, Apr. 1988, pp. 382-401. 

Hanson, E., “A Performance Analysis of View Materialization 
Strategies,” Proc. ACM SIGMOD, 1987, pp. 440-453. 

Kanth, M.R., and P.K. Bose, “Extending an Assumption-Based 
Truth Maintenance System to Databases,” Fourth IEEE Int’l Data 
Eng. Conf., IEEE CS Press, Los Alamitos, Calif., Order No. 827 
(microfiche only), 1988, pp. 354-361. 

Roussopoulos, N., and H. Kang, “Principles and Techniques in 
the Design of ADMS,” Computer, Vol. 19, No. 12, Dec. 1986, pp. 
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tied to a specific database or to a partic¬ 
ular application. 

Mediators are modules occupying an 
explicit, active layer between the user 
applications and the data resources. They 
will be accessed by application programs 
residing in the user workstations. (Re¬ 
call that our goal is a sharable architec¬ 
ture.) 

Mediators form a distinct middle lay¬ 
er, making the user applications inde¬ 
pendent of the data resources. What are 
the transforms needed in such a layer, 
and what form will the modules sup¬ 
porting this layer have? The responses 
to these questions are interrelated. 

Three architectural layers. We create 
a central layer by distinguishing the func¬ 
tion of mediation from the user-orient¬ 
ed processing and from database ac¬ 
cess. Most user tasks will need multiple, 
distinct mediators for their subtasks. A 
mediator uses one or a few databases. 

As Figure 4 shows, the interfaces to 
be supported provide the cuts where 
communication network services are 
needed. Unfortunately, the commonal¬ 
ity of functions described in the exam¬ 
ples (see the “Mediation” sidebar) does 
not extend to an architectural common¬ 
ality: All the examples cited are bound 
to the data resources and the end users’ 
applications in their idiosyncratic ways. 
This is where new technology must be 
established if fusion at the application 
level is to be supported. Accessing one 
mediator at a time does not allow for 
fusion, and seeing multiple results on 
distinct windows of one screen does not 
support automation of fusion. 

Mediators. Having listed some exam¬ 
ples of mediators in use or planned for 
' specific tasks, I offer this general defini¬ 
tion: A mediator is a software module 
that exploits encoded kndwTedgeabout 
certain sets or subsets of data to create 
information for a higher layer of appli¬ 
cations. 

\i We place the same requirements on a 
mediation module that we place on any 
software module: It should be small and 
simple 6 so that it can be maintained by 
one expert or, at most, by a small and 
coherent group of experts. 

An important, although perhaps not 
essential, requirement I’d like to place 
on mediators is that they be inspectable 
by potential users. For instance, the rules 
used by a mediator using expert system 
technology can be obtained by the user 


as in any good cooperative expert sys¬ 
tem. In this sense, the mediators pro¬ 
vide data about themselves in response 
to inspection, and such data could be 
analyzed by yet another mediator mod¬ 
ule, an inspector mediator. 

Since there will eventually be a great 
number and variety of mediators, users 
have to be able to choose among them. 
Inspectability enables that task. For in¬ 
stance, we might have distinct media¬ 
tors that can provide the names of the 
best consultants for database design. 
Alternate metamediators are likely to 
use different evaluation criteria; one 
may use the number of publications and 
another the number of clients. 

Some metamediators will have to ex¬ 
ist that merely provide access to cata¬ 
logs listing available mediators and data 
resources. The search may go either 
way: For a given data source, it may be 
necessary to locate a knowledgeable 
mediator; for a desirable mediator, we 
need to locate an adequate data re¬ 
source. It will be essential that the facil¬ 
ities provided by these metalevel medi¬ 
ators can be integrated into the general 
processing model, since search for in¬ 
formation is always an important aspect 
of information processing. Where search 
and analyses are separated — as is still 
common today in, for instance, statisti¬ 
cal data-processing—trying to find and 
understand the data is often the most 
costly phase of information processing. 

Since many databases are autono¬ 
mous, it is desirable that only a limited 
and recognizable set of mediators de¬ 
pend on any one of them. Focusing data 
access through a limited number of views 
maintained by these mediators provides 
the data independence necessary for 
databases that are evolving autonomous¬ 
ly. Currently, compatibility constraints 
are hindering growth of databases in 
terms of structure and scope, since many 
users are affected. As the number of 
users and the automation of access in¬ 
crease, the importance of indirect ac¬ 
cess via mediators will increase. 

Mediator interfaces. The two inter¬ 
faces to the mediator layer are the most 
critical aspect of this three-layer archi¬ 
tecture. Today’s mediating programs use 
a wide variety of interface methods and 
approaches. The user learns one or a 
few of them and remains committed to 
that choice until its performance be¬ 
comes wholly unacceptable. Unless the 
mediators are easily and flexibly acces¬ 


sible, the model of common informa¬ 
tion access I envisage is bound to re¬ 
main fictitious. The research challenge 
then lies in the interface and its support. 
Our hardware environment implies that 
mediators can live on any node, not just 
on workstation and database hosts. 

User’s workstation interface to the 
mediators. The range of mediator capa¬ 
bilities is such that a high-level lan¬ 
guage should evolve to drive them. Here, 
I am thinking of language concepts, rath¬ 
er than interface standards, to indicate 
the degree of extensibility that must be 
provided if the mediating concepts are 
to be generalized. 

Determining an effective interface 
between the workstation application and 
the mediators will be a major research 
effort in establishing systems sharing 
this architecture. It appears that a lan¬ 
guage is needed to provide flexibility, 
composability, iteration, and evaluation 
in this interface. Descriptive, but static, 
interface specifications seem unable to 
deal with the variety of control and the 
information flow that must be support¬ 
ed. The basic language structure should 
permit incremental growth so that new 
functions can be supported as media¬ 
tors join the network to provide new 
functionality. 

It is important to observe that I do 
not see a need for a user-friendly inter¬ 
face. What is needed here is a machine- 
and communication-friendly interface. 
Application programs executing on the 
users’ workstations can provide the type 
of display and manipulation functions 
appropriate to their users. Omitting the 
criterion of user friendliness avoids the 
dichotomy that has led to inadequacies 
in the Structured Query Language 
(SQL), which tries to be user friendly, 
while its predominant use is for pro¬ 
grammed access. 7 Standards needed here 
can only be defined after experience 
has been obtained in sharing these re¬ 
sources to support the high-level func¬ 
tions needed for decision making. 

The mediator to the database manage¬ 
ment system interface. Existing database 
standards, such as SQL and the Remote 
Data Access (RDA) protocol, provide 
a basis for database access by media¬ 
tors. Relational concepts — selection, 
views, etc. — are a good starting point, 
but much flexibility is possible. A medi¬ 
ator dealing with a specific database 
need not be constrained to a particular 
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Result —> Decision making 

User layer: Independent applications — managed by decision-makers 

on workstations 

- network services to information servers - 

Mediator layer: Multiple mediators — managed by domain 

specialists 

- network services to data servers . 

Base layer: Multiple databases,... — managed by database 

administrators 

Input <— real-world changes 
Figure 4. Three layers of a mediator architecture. 


protocol, while a more general media¬ 
tor will gain applicability through a stan¬ 
dard interface. A mediator that com¬ 
bines information from multiple 
databases can use its knowledge to con¬ 
trol the merging process, specifying re¬ 
lational operations directly. Joins may, 
for instance, be replaced by explicit semi¬ 
joins, so that intelligent filtering can 
occur during processing. Still, dealing 
with multiple sources is likely to lead to 
incompleteness. Outer-joins are often 
required for data access to avoid losing 
objects with incomplete information. 

New access languages are needed to 
manage sensor-based and simulation 
processes. Such systems also provide 
data to be abstracted and fused. 

The separation of user applications 
and data sources provided by mediating 
modules allows reorganization of data 
structures and redistribution of data over 
the processing nodes of communication 
networks without affecting the func¬ 
tionality of the modules. The three-lay¬ 
er architecture then makes an explicit 
trade-off favoring flexibility over inte¬ 
gration. The argument is the distinction 
of data and the results of mediator mod¬ 
ules: 

• Sharability of information requires 
that database results can be configured 
according to one of several views. Me¬ 
diators, being active, can create objects 
for a wide variety of orthogonal views. 

• Making complex objects themselves 
persistent, on the other hand, binds 
knowledge to the data — hampering 
sharability. 

• The loss of performance due to the 
interposition of a mediator can be over¬ 
come, for instance, via techniques listed 
in the section entitled “SODs.” 

These arguments do not yet address the 
distribution of the mediators I envisage. 

Available interfaces. We need inter¬ 
face protocols for data and knowledge. 
Mediation defines a new layer within 
the application layer defined by the 
open-system architecture. Open-systems 
layers will soon provide good communi¬ 
cation support. 

However, as mentioned earlier, com¬ 
munication of data alone does not guar¬ 
antee that the data will be correctly 
understood for processing by the re¬ 
ceiver. Mediation considers the mean¬ 
ing assigned to the bits stored; Figure 2 
contains some examples. 


Sharing of mediator modules. Since 
we are getting access to so much more 
data from a variety of sources, which 
are arriving at ever higher rates, auto¬ 
mated processing will be essential. The 
processing tasks needed within the me¬ 
diators — selection, fusion, reduction, 
abstraction, and generalization — are 
sketched in the interaction model of 
Figure 3. Diverse mediator modules will 
combine these functions in various ways 
to serve user applications at the deci¬ 
sion-making layer above. 

The mediator modules will be most 
effective if they can serve a variety of 
applications. The applications will com¬ 
pose their tasks as much as possible by 
acquiring information from the set of 
available mediators. Unavailable infor¬ 
mation may motivate the creation of 
new mediators. 

Sharing reinforces the need for two 
types of partitioning. First, there are the 
three horizontal layers supporting end 
users, mediators, and databases. Sec¬ 
ond, each of those layers will be verti¬ 
cally partitioned. There will be multi¬ 


ple-user applications, each using vari¬ 
ous configurations of mediators. Each 
of the mediators in turn will use distinct 
views over one or several databases. 
Vertical partitioning does not create a 
hierarchy. Just as databases are justi¬ 
fied by a diversity of shared usage, me¬ 
diators should be sharable. Today’s ex¬ 
pert systems are rarely modular and 
sharable, so their development and 
maintenance cost is harder to amortize. 

For instance, the mediation module 
that can deal with inflation adjustment 
can be used by many applications. The 
mediator that understands postal codes 
and town names can be used by the post 
office, express delivery services, and 
corporate mail rooms. 

Partitioning leads to modules, as 
sketched in Figure 5. 

Distribution of mediators. I have im¬ 
plied throughout this article that medi¬ 
ators are distinct modules, distributed 
over the network. Distribution can be 
motivated by greater economy for ac¬ 
cess, by better locality for maintenance, 


|llser 11 |User 2| |User 3| |User 4| |User 5| |User /1 |l)ser/t| |User n| 
Query! Relevant responsesT Inspection! 

| Mediator 71 | Mediator A~[ | Mediator 7] | Mediator 7r7| <-» Experts 

Formatted query! Bulky responsesT Triggered events! 

| Database~w1 | Database"*] | Database'll . I Patabase~F| 

All | modules | are distributed over nationwide networks. 

Figure 5. Interfaces for information flow. 
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and by autonomy. For mediators the 
two latter arguments are the driving 
force for distribution. 

Why shouldn’t mediators be attached 
to databases? In many cases, that may 
be feasible; in general it is not appropri¬ 
ate because 

• A mediator contains knowledge that 
is beyond the scope of the database 
proper. A database programmer deal¬ 
ing with, say, a factory production-con¬ 
trol system cannot be expected to fore¬ 
see all the strategic uses of the collected 
information. 

• Concepts of abstraction are not part 
of database technology today. The fo¬ 
cus has been on reliable and consistent 
management of large volumes of de¬ 
tailed facts. 

• Intelligent processing of data will 
often involve dealing with uncertainty, 
adding excessive and undesirable com¬ 
plexity to database technology. 

• Many mediators will access multi¬ 
ple databases to combine disjointed sets 
of data prior to analysis and reduction. 

Similarly, we can argue that the medi¬ 
ators should not be bound to the users’ 
workstation applications. Again, the 
functions that mediators provide are 
different in scope from the tasks per¬ 
formed on the workstations. Worksta¬ 
tion applications might use a variety of 
mediators to explore the data resources. 

Maintenance issues, a major motiva¬ 
tion for keeping mediators distinct, have 
received insufficient attention in the past. 
During the initial stage of most projects 
that developed expert systems, knowl¬ 
edge bases simply grew and the cost of 
knowledge acquisition dominated the 
cost of knowledge maintenance. Many 
projects, in fact, assumed implicitly that 
knowledge, once obtained, would re¬ 
main valid for all times. Although some 
fundamental rules may indeed not 
change for a long time, new concepts 
arise, older ones are partitioned, and 
definitions are refined as demands 
change. The importance of knowledge 
maintenance leads to systems composed 
of small knowledge units focused on 
specific domains. 8 

Maintenance of knowledge stored 
within an application by an outside ex¬ 
pert system is intrusive and risky. The 
end user should make the decision when 
to incorporate new knowledge. It is best 
to keep the mediator modules distinct 
from the applications. 


Mediators are associated with the 
domain expert, but may be replicated 
and shipped to other network nodes to 
increase their effectiveness. Specializa¬ 
tion increases the power and maintain¬ 
ability of the mediators and provides 
choices for users. The efficiency con¬ 
cerns of separating knowledge in medi¬ 
ators and data in databases can be mit¬ 
igated by replication. Since mediators 
(incorporating only knowledge and no 
factual data) are relatively stable, they 
can be replicated as needed and copied 
onto nodes along the data highway where 
they are maximally effective. Their con¬ 
tent certainly should not change during 
a transaction. As long as the mediators 
remain small, they can also be easily 
shipped to a site where substantial data 
volumes have to be processed. 

Triggers for knowledge maintenance. 

I have incorporated one aspect of medi¬ 
ation into Figure 5 that has not yet been 
discussed. Since the knowledge in the 
mediator must be kept up to date, plac¬ 
ing triggers or active demons in data¬ 
bases 2 is useful. Now the mediators can 
be informed when the database and, by 
extension, the real world changes. The 
owner of the mediator should ensure 
that such changes are, in due time, re¬ 
flected in the mediator’s knowledge base. 

Again justified by the analogy to hu¬ 
man specialists, I consider that a medi¬ 
ator is fundamentally trustworthy but is 
inspectable when suspicions of obso¬ 
leteness arise. For instance, an assump¬ 
tion, say, that well-to-do people buy big 
cars may be used in the marketing medi¬ 
ator, but it is possible that over time this 
rule will become invalid. I expect that 
the base data will be monitored for 
changes and that exceptions to data¬ 
base constraints will trigger informa¬ 
tion flow to the mediator. In a rule- 
based mediator the certainty factor of 
rules can be adjusted. If the uncertainty 
exceeds a threshold, the mediator can 
advise its creator, the domain expert, to 
abandon this rule. The end user need 
not get involved. 9 

Related research 

We have seen that many of the indi¬ 
vidual concepts underlying this archi¬ 
tecture were found in earlier work. This 
is hardly surprising, since the problems 
that future information systems must 
address exist now and are being dealt 


with in many specific situations. Rather 
than extrapolating into the unknown, I 
define an architecture that is based on a 
number of known concepts. 

Object-oriented concepts. We have 
great expectations from object-orient¬ 
ed concepts, since these provide a se¬ 
mantic, meaningful clustering of relat¬ 
ed data and methods. A mediator can 
be viewed as an autonomous superob¬ 
ject. It also hides the representation of 
the underlying data. However, the me¬ 
diator should be accessed by a higher 
level language. Internally, the choice of 
language is not restricted. 

An important difference between 
mediators and objects is in their scale. 
This difference is reflected in their scope 
and ownership. Mediators are indepen¬ 
dent units and have to deal with multi¬ 
ple applications. Furthermore, they do 
not need to encapsulate data. 

The network of connections within 
the global architecture means that dis¬ 
tinct tasks can intersect at nodes within 
this information-processing structure. 
The same mediator type may access 
distinct sets of data, and information 
from one data source can be used by 
distinct mediators. Sources can include 
object databases. 

Independent actors and agents. Inde¬ 
pendence is even more prominent in 
the concept of Actors, as proposed by 
Hewitt. 10 In an Actor architecture, mod¬ 
ules operate independently but are as¬ 
sumed to cooperate towards a common 
goal. Mediators do not act independent¬ 
ly. They respond to queries from appli¬ 
cations or to triggers placed in databas¬ 
es. They do not interact intelligently 
with each other; a hierarchy is imposed 
for every specific task. This limitation 
provides computational simplicity and 
manageability. The extent to which net¬ 
works of autonomous Actors can be 
motivated is unclear. 

The concepts underlying Agents, as 
developed to control robot activities, 
are based on control mechanisms simi¬ 
lar to those in mediators. Such Agents 
do not yet deal with abstractions, mis¬ 
match, and autonomous data resources. 

Maintenance and learning. The 

knowledge embodied in mediators can¬ 
not be permitted to be static. Knowl¬ 
edge maintenance is based on feedback. 

In effective organizations, lower levels 
of management involved in informa- 
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tion processing provide feedback to su¬ 
perior layers. 

Knowledge in mediators will initially 
be updated by human experts. For ac¬ 
tive knowledge domains, some auto¬ 
mation will be important. Checking for 
inconsistencies between acquired data 
and assumed knowledge is the next 
step. 

Eventually, some mediators will be 
endowed with learning mechanisms. 
Feedback for learning might either come 
from performance measures or from 
explicit induction over the databases 
they manage. Learning is triggered by 
monitors placed in the database. Ideal¬ 
ly, every rule in the mediator is related 
to triggers. For instance, the rule 
“Wealthy people buy big cars” requires 
triggers on income and car ownership. 
Now, changes in the database can con¬ 
tinuously update hypotheses of interest 
within the mediator. 

Learning by modifying certainty pa¬ 
rameters in the knowledge base is rela¬ 
tively simple. Tabular knowledge — or 
say, a list of good customer types — can 
be augmented. Learning new concepts 
is much more difficult, since we have no 
mechanisms that relate observations 
automatically to unspecified symbolic 
concepts. By initially depending fully 
on the human expert to maintain the 
mediator and later updating parame¬ 
ters of rules, we can gradually move to 
automated learning. 

Implementation techniques. Media¬ 
tors will embody a variety of techniques 
now found in freestanding applications 
and programs that perform mediation 
functions. These programs are now of¬ 
ten classified by the underlying scientif¬ 
ic area rather than by their place in 
information systems. 

The nature of mediators is such that 
many techniques developed in artificial 
intelligence will be employed. We ex¬ 
pect that mediators will often use 

• declarative approaches, 

• capability for explanation, 

• heuristic control of inference, 

• pruning of candidate solutions, 

•evaluation of the certainty of re¬ 
sults, and 

• estimation of processing costs for 
high-level optimization. 

The literature on these topics is broad. 5 
Heuristic approaches are likely to be 
important because of the large solution 


spaces. Uncertainty computations are 
needed to deal with missing data and 
mismatched natural classes. 

SODs. The knowledge-based man¬ 
agement systems (KBMS) project group 
at Stanford University has formulated a 
specific form of mediator, which focus¬ 
es on well-structured semantic domains 
of discourse (SODs). 11 A SOD provides 
a declarative structure for the domain 
semantics, suitable for an interpreter. 
We see multiple SODs being used by an 
application, executing a long and inter¬ 
active transaction. 

I summarize our concepts here as one 
research avenue for the architecture I 
have presented. 

Specific features and constraints im¬ 
posed on SODs are 

• The knowledge should be represent¬ 
ed in a declarative form. 

• Each should have a well-formed lan¬ 
guage interface. 

• Each should contain feature descrip¬ 
tions exploitable by the interpreter. 

• Each should be inspectable by the 
user applications. 

• Each should be amenable to paral¬ 
lel execution. 

• Each accesses the databases through 
relational views. 

• During execution, source data and 
derived data objects are bound in 
memory. 

• Each can share instances of objects. 

By placing these constraints on SODs 
as mediators, proofs of their behaviors 
and interaction are feasible. Provable 
behavior is not only of interest to devel¬ 
opers, but also provides a basis for pre¬ 
diction of computational efficiency. 

However, the modularity of SODs 
causes two types of losses: 

(1) Loss in power, due to limitations 
in interconnections. 

(2) Loss in performance, due to reli¬ 
ance on symbolic binding rather 
than on direct linkages. 

We hope to offset these losses through 
gains obtained from having structures 
that enable effective computational 
algorithms. An implementation of a 
demonstration using frame technology 
is being expanded. Of course, the long- 
range benefit is that small, well- 
constructed mediators will enable 
knowledge maintenance and growth. 


Interface language. Defining the lan¬ 
guage needed to effectively invoke a 
variety of mediators is the major issue. 
If we cannot express the high-level con¬ 
cepts encapsulated in the mediators well, 
we will not be able to implement the 
required services. For application ac¬ 
cess to SODs, we start from database 
concepts, where high-level languages 
have become accepted. The SOD ac¬ 
cess language (SODAL) must include 
the functional capabilities of SQL, plus 
iteration, test, and ranking. New predi¬ 
cates are needed to specify intelligent 
selection. Selection of desirable objects 
requires an ability to rank objects ac¬ 
cording to specified criteria. These cri¬ 
teria are understood by the SOD and 
are not necessarily predicates on under¬ 
lying data elements, although for a triv¬ 
ial SOD that may be true. These criteria 
are associated with such result size pa¬ 
rameters as “Give me the 10 best X," 
where the best predicate is a semanti¬ 
cally overloaded term interpreted in¬ 
ternally to a particular SOD. 

Given an application to find review¬ 
ers for an article, the Expertise SOD 
will rank candidate scientists by best 
match to the article’s keywords, while a 
Competency SOD will rank the candi¬ 
dates by the quality of their publication 
record. Other SODs can assess the po¬ 
tential bias and responsiveness of the 
candidates. 

The format of SODAL is not user 
friendly; after all, other subsystems will 
use the SODs, not people. It should 
have a clear and symmetric structure 
that is machine friendly. It should be 
easy to build a user-friendly interface, if 
needed, on top of a capable SODAL. 

Limits and extensions 

The separation into layers envisaged 
here reduces the flexibility of informa¬ 
tion transfer. Structuring the mediators 
into a single layer between application 
and data is overly simplistic. Precursors 
to general mediators already recognize 
hierarchies and general interaction, as 
Actors do. 10 

The simple architecture described 
here is intended to serve large-scale 
applications. To assure effective exploi¬ 
tation of the mediator concepts, I pro¬ 
pose to introduce complexity within lay¬ 
ers slowly, only as the foundations are 
established to permit efficient use. 

Structuring mediators into hierarchies 
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A futuristic world 
with mediators 


A mediator contains an expert’s 
knowledge and makes that exper¬ 
tise available to applications cus¬ 
tomers. 

One can envisage a world 
where mediators can be pur¬ 
chased or leased for use. A mar¬ 
ket for mediators enables experts 
to function as knowledge genera¬ 
tors and sell their knowledge in a 
form that is immediately usable. 
Traditional papers and books are 
a knowledge representation that 
requires extensive human inter¬ 
pretation. To apply the knowledge 
from a book to actual data, a pro¬ 
gram has to be written and tested. 
The knowledge in a mediator is 
ready for consumption. 

There will be a trade-off in such 
a market between mediators that 
are powerful and highly special¬ 
ized and mediators that are more 
basic and more general. The latter 
will sell more copies but at a lower 
price. 

A mediator that contains very 
valuable knowledge may only be 
made available for use on its 
home computer, since limited ac¬ 
cess can greatly reduce the risk of 
unauthorized copying. 

A market economy of mediators 
will greatly change the interaction 
between knowledge workers. Pub¬ 
lication volume will decrease. Me¬ 
diators that are incomplete, incor¬ 
porate foolish assumptions, or 
contain errors will soon lose their 
credibility. A review mediator can 
make user comments available to 
a wide community. To introduce 
new and improved mediators, ad¬ 
vertisements can be posted via a 
news mediator. Metamediators 
can process advertisements and 
reviews to help applications make 
sensible decisions. 


should not lead to problems. We al¬ 
ready required that directory mediators 
could be inspected. Directory media¬ 
tors can help select other mediators by 
inspecting them and analyzing their ca¬ 
pabilities. High-level mediators can 
obtain help in locating and formatting 
data from lower level mediators. Low- 
level mediators might only have data¬ 


base access knowledge and understand 
little about application-domain seman¬ 
tics. Optimizers may restructure the 
information flow, taking into account 
success or failure with certain objects 
in one of the involved SODs. 

More complex is lateral information¬ 
sharing among mediators. Some such 
sharing will be needed to maintain the 
lexicons that preserve object identity 
when distinct mediators group and clas¬ 
sify data. Fully general interaction be¬ 
tween mediators is not likely to be 
supported at this level of abstraction. 
Just as human organizations are will¬ 
ing to structure and constrain interac¬ 
tions, even at some lost-opportunity 
cost, we impose similar constraints on 
the broad information systems we en¬ 
visage. 

Requirements of data security will 
impose further constraints. Dealing 
with trusted mediators, however, may 
encourage database owners to partici¬ 
pate in information sharing to a great¬ 
er extent than they would if all partic¬ 
ipants would need to be granted 
file-level access privileges. 


T he proposed generalization of 
practices seen today takes ad¬ 
vantage of modern hardware. 
The architecture can focus a variety of 
research tasks needed to support such 
systems. Some extensions, such as gen¬ 
eral uncertainty algebras, are beyond 
today’s conceptual foundations. As 
stated earlier, we can take a cue from 
Vannevar Bush, 3 who could identify 
all units needed for the Memex — al¬ 
though its components were based on 
technology that did not exist in 1945. 

A language will be needed to pro¬ 
vide flexibility in the interaction be¬ 
tween the end users’ workstation and 
the mediators. The partitioning of arti¬ 
ficial intelligence paradigms into prag¬ 
matics (at the user-workstation layer) 
and the formal infrastructure (in the 
mediation layer) are discussed else¬ 
where. 11 

For query operations, the control 
flow goes from the application to the 
mediator. There, the query is first in¬ 
terpreted to plan optimal database ac¬ 
cess. The data obtained from that da¬ 
tabase would flow to the mediator, be 
aggregated, reduced, pruned, and so 
on, and the results reported to the 
query originator. Multiple mediators 
serve an application with pieces of in¬ 


formation from their subdomains. Good 
scheduling is critical. 

The knowledge-based paradigms in¬ 
herent in intelligent mediators indicate 
the critical role of artificial intelligence 
technology foreseen when implement¬ 
ing mediators. 

Mediators may be strengthened by 
having learning capability. Derived in¬ 
formation may simply be stored in a 
mediator. Learning can also lead to new 
tactics of data acquisition and control of 
processing. 

It is not the intent of the mediator- 
based model to be exclusive and rigid. 
The model is intended to provide a com¬ 
mon framework under which many new 
technologies can be accommodated. An 
important objective is to utilize a vari¬ 
ety of information sources without de¬ 
manding that they be brought into a 
common internal format. 

In a 1990 report, 12 the three primary 
issues to be addressed in knowledge- 
based systems were listed as mainte¬ 
nance, problem modeling, and learning 
and knowledge acquisition. The archi¬ 
tecture presented here contributes to 
all three issues, largely by providing a 
partitioning that permits large systems 
to be composed from modules that are 
maintainable. ■ 
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A Taxonomy and Current 
Issues in Multidatabase 
Systems 

M.W. Bright, A.R. Hurson, and Simin H. Pakzad 
Pennsylvania State University 


Global access and local 
autonomy are central 
to multidatabase 
system design. This 
article draws on other 
information-sharing 
systems research to 
define key issues. 


information is a key resource in the daily operation of business, government, 

■ and academic organizations. Today, organizational information is frequent- 
ly represented in computer databases. As organizations and users become 
more sophisticated, the sharing of information resources also increases. For 
example, the French Teletel system currently gives 1.8 million users access to more 
than 1,500 separate databases. 

However, a multitude of systems usually means multiple access methods and 
user paradigms. It is unreasonable to ask users to learn all these access methods, 
yet it is also unreasonable to expect organizations to convert all their systems to a 
single common data model with a single access method. Multidatabase systems 
give users a common interface to multiple databases, while minimizing the impact 
on existing database operations. 

Database systems often serve critical functions and represent significant capital 
investment. Many organizations have several different computers and database 
systems. In many cases, this environment must be preserved while also addressing 
the need to share information on a more global basis. Integrated access is required 
to semantically similar information at different nodes and with different data 
representations. Multidatabases typically integrate information from preexisting, 
heterogeneous local databases in a distributed environment and present global 
users with transparent methods to use the total information in the system. A key 
feature is the autonomy that individual databases retain to serve their existing 
customer set. 

Multidatabases are an important area of current research, as evidenced by the 
number of projects in both academia and industry. The trade press has also 
documented the need for user-friendly global information sharing. The next level 
of computerization will be distributed global systems that can share information 
from all participating sites. Multidatabases are a key component of this advancing 
technology. 

This article presents a taxonomy of global information-sharing systems and 
discusses where multidatabase systems fit in the spectrum of solutions. We use this 
taxonomy as a basis for defining multidatabase systems, then we discuss the issues 
associated with them. We pay particular attention to the two major design 
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approaches for multidatabases — glo¬ 
bal schema systems and multidatabase 
language systems. We list and briefly 
characterize existing multidatabase 
projects and conclude with a discussion 
of areas for further research. 

What is a 
multidatabase? 

Taxonomy of global information-shar¬ 
ing solutions. There is a wide range of 
solutions for global information shar¬ 
ing in a distributed system, and the liter¬ 
ature uses a variety of terms to describe 
them. The terms include distributed 
databases, multidatabases, federated 
databases, and interoperable systems. 
All these terms describe a distributed 
system that includes a global compo¬ 
nent to access globally shared informa¬ 
tion and multiple local components that 
manage only information at that site. 
The distinctions are in the structure of 
the global component and how it inter¬ 
acts with local components. Current 
usage of these terms varies somewhat 
between authors. Therefore, we first 
present a taxonomy to distinguish more 
concretely between systems. 

Our taxonomy orders the solutions 
according to how tightly the global sys¬ 
tem integrates the local database man¬ 
agement systems. A tightly coupled sys¬ 
tem means the global functions have 
access to low-level internal functions of 


the local DBMS. This allows close syn¬ 
chronization among sites and efficient 
global processing (possibly at the ex¬ 
pense of local efficiency). However, it 
also implies that global functions may 
have priority over local functions and, 
therefore, that local DBMSs do not have 
full control over local resources. In a 
more loosely coupled system, the global 
functions access local functions through 
the DBMS’s external user interface. 
Global synchronization and efficiency 
are not as high as in the tightly coupled 
case, but local DBMSs have full control 
over local data and processing (site au¬ 
tonomy). In the most loosely coupled 
system, there are few global functions 
(just raw data exchange) and the local 
interface to global information is through 
applications residing above the local 
DBMS user interface. The definitions 
below begin with the most tightly cou¬ 
pled systems and proceed to the most 
loosely coupled. Table 1 shows the ma¬ 
jor distinctions between classes. 

Distributed databases. A distributed 
database is the most tightly coupled 
global information-sharing system. Glo¬ 
bal and local functions share low-level 
internal interfaces and are so tightly 
integrated that there is little distinction 
between them. Distributed databases, 
therefore, are typically designed in a 
top-down fashion, with global and local 
functions implemented simultaneous¬ 
ly. The local DBMSs are typically ho¬ 
mogeneous (with respect to the data 


model implemented) and present the 
same functional interfaces at all levels, 
even though they may be implemented 
on different machines. The global sys¬ 
tem has control over local data and pro¬ 
cessing. The system typically maintains 
a global schema created by integrating 
the schemas of all the local DBMSs. A 
schema is a structured description of 
the information available in a database. 
Global users access the system by sub¬ 
mitting queries over the global schema. 
Because they are so tightly integrated, 
distributed databases can closely syn¬ 
chronize global processing. Further¬ 
more, since the global functions have 
complete control over local functions, 
processing can be optimized for global 
requirements. As a result, distributed 
databases have good global perfor¬ 
mance, but at the cost of significant 
local modification and loss of control. 
Ceri and Pelagatti provide a good intro¬ 
duction to distributed databases. 1 

Global schema multidatabases. Glo¬ 
bal schema multidatabases are more 
loosely coupled than distributed data¬ 
bases because global functions access 
local information through the external 
user interface of the local DBMS. How¬ 
ever, the global system still maintains a 
global schema, so the local sites must 
cooperate closely to maintain the glo¬ 
bal schema. Global schema multidata¬ 
bases are typically designed bottom-up 
and can integrate preexisting local 
DBMSs without modifying them. They 


Table 1. Taxonomy of global information-sharing systems. 


Class 

Level of Global 
Interface to Local 
DBMS 

Local Node 

Types 

Full Global 

Database 

Function 

Method of Global 
Integration 

Distributed database 

Internal DBMS 
functions 

Homogeneous databases 

Yes 

Global schema 

Global schema 
multidatabase 

DBMS user interface 

Heterogeneous databases 

Yes 

Global schema 

Federated database 

DBMS user interface 

Heterogeneous databases 

Yes 

Partial global schemas 

Multidatabase 
language system 

DBMS user interface 

Heterogeneous databases 

Yes 

Access language functions 

Homogeneous 
multidatabase 
language system 

DBMS user interface 
plus some internal 
DBMS functions 

Homogeneous databases 

Yes 

Access language functions 

Interoperable 

systems 

Application on 
top of the DBMS 

Any data source that meets 
the communication protocol 

No 

No global integration 
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also normally integrate heterogeneous 
local DBMSs. This heterogeneity may 
mean different data models or different 
implementations of the same data mod¬ 
el. Thus, creating the global schema is a 
more difficult problem than in a distrib¬ 
uted database, where the local DBMSs 
are homogeneous and the global data¬ 
base administrator (DBA) has control 
over the local schema input to the glo¬ 
bal schema. 

Federated databases. Federated data¬ 
bases are a more loosely coupled subset 
of global schema multidatabases. There 
is no single global schema: Each local 
system maintains a local import and 
export schema. The export schema is a 
description of the information the local 
node is sharing with the global systems. 
The import schema is a description of 
the information (both data representa¬ 
tion and data origin) from remote nodes 
that may be accessed locally. Each im¬ 
port schema is in essence a partial glo¬ 
bal schema. Therefore, each node must 
cooperate closely only with the specific 
nodes it accesses. User queries are re¬ 
stricted to local data and the data repre¬ 
sented in the local import schema. 

Multidatabase language systems. Mul¬ 
tidatabase language systems are more 
loosely coupled than the previous class¬ 
es because no (partial) global schema is 
maintained. The global system supports 
all global database functions by provid¬ 
ing query language tools to integrate 
information from separate databases. 
User queries can specify data from the 
local schema of any node participating 
in the system. Language tools include a 
global name space and special functions 
to map information from different mod¬ 
els and representations to a model and 
representation meaningful to the user. 
Like global schema multidatabases, 
multidatabase language systems inte¬ 
grate preexisting, heterogeneous local 
DBMSs without modifying them. 

Homogeneous multidatabase language 
systems. Homogeneous multidatabase 
language systems are a degenerate form 
of multidatabase language systems. This 
subset merits its own class because there 
are a number of existing multidatabase 
projects that currently support only 
homogeneous local DBMSs, and these 
include some of the first commercial 
multidatabase systems. The commer¬ 
cial products tend to have limited lan¬ 


guage functions- compared with the 
projects in the previous class. Some of 
these systems are actually rather tightly 
coupled because they allow some glo¬ 
bal/local interaction below the standard 
user interface. However, these excep¬ 
tions are infrequent. Because of the 
exceptions, members of this class ex¬ 
hibit some characteristics of distributed 
databases as well as multidatabases. 

Interoperable systems. Interoperable 
systems are the most loosely coupled 
information-sharing systems. Global 
function is limited to simple data ex¬ 
change and does not support full data¬ 
base functionality. Standard protocols 
are defined for communication among 
the nodes. Because the global system is 
not database oriented, local systems may 
include other types of information re¬ 
positories, such as expert systems or 
knowledge-based systems. Interopera¬ 
ble systems are still mainly in the re¬ 
search stage. 

Definition of multidatabases. For the 

purposes of this article, the generic term 
multidatabase will include the classes of 
global schema multidatabase, federat¬ 
ed database, multidatabase language 
system, and homogeneous multidata¬ 
base language system. A multidatabase 
is a distributed system that acts as a 
front end to multiple local DBMSs or is 
structured as a global system layer on 
top of local DBMSs. The global system 
provides full database functionality and 
interacts with local DBMSs at their ex¬ 
ternal user interface. Although each local 
node must maintain some global func¬ 
tion to interface with the global system, 
the local DBMSs are autonomous. The 
global system provides some means (glo¬ 
bal schema or multidatabase language) 
of resolving the differences in data rep¬ 
resentation and function between local 
DBMSs. This resolution capability is 
necessary because the same informa¬ 
tion may be maintained at multiple lo¬ 
cations in different forms. The global 
user can access information from multi¬ 
ple sources with a single relatively sim¬ 
ple request. 


Issues in 
multidatabases 


Site autonomy. A key aspect of mul¬ 
tidatabases, as opposed to distributed 


databases, is that each local DBMS re¬ 
tains complete control over local data 
and processing. This is called site auton¬ 
omy. 2 Each site independently deter¬ 
mines what information it will share 
with the global system, what global re¬ 
quests it will service, when it will join 
the multidatabase, and when it will stop 
participating in it. The DBMS itself is 
not modified by joining the multidata¬ 
base. Neither global changes, such as 
addition and deletion of other sites, nor 
global optimization of data structures 
and processing methods has any effect 
on the local DBMS. Local DBAs are 
free to optimize local data structures, 
access paths, and query-processing meth¬ 
ods to satisfy local user requirements 
rather than global requirements. Since 
the global system interfaces with the 
local DBMS at the user level, the local 
DBMS sees the global system as just 
another local user. Note that site auton¬ 
omy applies to the local DBMS rather 
than the local system as a whole. The 
local system must support some subset 
of the global function. 

The multidatabase approach of pre¬ 
serving site autonomy may be desirable 
for several reasons. Some local data¬ 
bases may have critical roles in an orga¬ 
nization, and it may be impossible from 
an economic standpoint to change these 
systems. Site autonomy means the local 
DBMS can add global access without 
changing this existing local function. 
Another economic factor is that an or¬ 
ganization may have significant capital 
invested in existing hardware, software, 
and user training. All of this investment 
is preserved when joining a multidata¬ 
base because existing local applications 
can continue operating unchanged. Site 
autonomy can also act as a security 
measure because the local DBMS has 
full control over who accesses local re¬ 
sources through the multidatabase in¬ 
terface and what processing options will 
be allowed. In particular, a site can pro¬ 
tect information by not including it in 
the local schema that is shared with the 
global system. An organization’s re¬ 
quirement for global access may be min¬ 
imal or sporadic. Site autonomy allows 
the local DBMS to join and quit the 
multidatabase with minimal local im¬ 
pact. 

Despite the desirable aspects of site 
autonomy, it places a large burden on 
global DBAs. Each site has indepen¬ 
dent local requirements and makes in¬ 
dependent local optimizations to satis- 
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fy those requirements. Because of this 
independence and the possibly large 
number of participating sites, global 
requirements and desirable global opti¬ 
mizations (of global data structures, 
access paths, query-processing methods, 
etc.) are likely to conflict with local 
ones. The global DBA must work around 
these conflicts in initial global system 
design and ongoing global maintenance. 
Because of the heterogeneity of local 
DBMSs, the global system may have to 
dedicate global resources to compen¬ 
sate for any missing local function or 
information. Some of these problems 
may be alleviated somewhat if the local 
DBAs agree to cooperate and conform 
to some global standards. 

Differences in data representation. 

There are many ways to model a given 
real-world object (or relationships to 
other objects), depending on how the 
model will be used. 3 Because local data¬ 
bases are developed independently with 
differing local requirements, a multi 
database system is likely to have many 
different models, or representations, for 
similar objects. However, a global user 
desires an integrated presentation of 
global information without duplications 
or heterogeneity. 

Name differences. Local databases 
may have different conventions for nam¬ 
ing objects, leading to the problems of 
synonyms and homonyms. Synonym 
means the same data item has different 
names in different databases. The glo¬ 
bal system must recognize the semantic 
equivalence of the items and map the 
differing local names to a single global 
name. Homonym means different data 
items have the same name in different 
databases. The global system must rec¬ 
ognize the semantic difference between 
items and map the common names to 
different global names. 

Format differences. Format differenc¬ 
es include differences in data type, do¬ 
main, scale, precision, and item combi¬ 
nations. For example, a part number 
may be defined as an integer in one 
database and as an alphanumeric string 
in another. Sometimes data items are 
broken into components in one data¬ 
base while the combination is recorded 
as a single quantity in another. 

Multidatabases typically resolve for¬ 
mat differences by defining transforma¬ 
tion functions between the local and 


A multidatabase system is 
likely to have many different 
representations for similar 
data objects. 


global representations. Some functions 
may be simple numeric calculations such 
as converting square feet to acres. Oth¬ 
ers may require tables of conversion 
values or algorithmic transformations. 
A problem in this area is that the local- 
to-global transformation may be sim¬ 
ple, but the inverse transformation (re¬ 
quired if updates are supported) may be 
very complex. 

Structural differences. Depending on 
how an object is used by a database, it 
may be structured differently in differ¬ 
ent local databases. A data item may 
have a single value in one database and 
multiple values in another. An object 
may be represented as a single relation 
in one place or as multiple relations in 
another. The same item may be a data 
value in one place, an attribute in an¬ 
other, and a relation in a third place. 

Missing or conflicting data. Databas¬ 
es that model the same real-world ob¬ 
ject may have conflicts in the actual 
data values recorded. One system may 
not have some information recorded 
due to incomplete updates, system er¬ 
ror, or insufficient demand to maintain 
such data. More serious is the case where 
two databases record the same data item 
but give it different values. The values 
may differ because of an error or be¬ 
cause of valid differences in underlying 
semantics. 

Heterogeneous local databases. Many 
multidatabases claim to support heter¬ 
ogeneous data models at the local level 
— generally, the network, hierarchical, 
and relational models. The support 
mainly consists of providing local trans¬ 
lation capability from the local model 
to the common global model, typically 
relational. Even systems that only sup¬ 
port relational DBMSs may be hetero¬ 
geneous to some degree. The relational 
data model is a theoretical model and 
different implementations may inter¬ 
pret the theoretical model differently. 


Supporting local DBMS heterogene¬ 
ity requires a trade-off between writing 
translation code and limiting participa¬ 
tion. If the multidatabase developers 
are willing to write enough translation 
code (considering development costs and 
execution efficiency), the multidatabase 
can accept a wide variety of local DBMSs. 
Another consideration here is that glo¬ 
bal system software must program any 
local functional deficiencies. If mini¬ 
mizing translation code cost is impor¬ 
tant, then the variety of DBMSs al¬ 
lowed to join the multidatabase will be 
limited to those with interfaces close to 
the global standard. 

Global constraints. Because differ¬ 
ent local databases may represent se¬ 
mantically equivalent data or semanti¬ 
cally related data, the global system 
needs some method for specifying and 
enforcing integrity constraints on inter¬ 
database dependencies and relationships 
(global constraints). These constraints 
may represent additional semantic in¬ 
formation about the data items involved. 

Global integrity constraints are some¬ 
times defined as part of the global sche¬ 
ma. Other multidatabases keep sepa¬ 
rate auxiliary databases specifying global 
constraints. The query processor checks 
these auxiliary databases during query 
execution to enforce the constraints. 

Global constraints require a thorough 
system policy statement that defines how 
to manage them. An example is an in¬ 
terdatabase update dependency, where 
updating an object in one database 
should update an equivalent object in 
another database. If the update is to be 
propagated, the site autonomy of the 
second node may be compromised. If 
the update is not to be propagated, the 
first site must either reject updates (re¬ 
strict function) or accept them (violate 
the constraint and cause data inconsis¬ 
tency). 

Global query processing. The basics 
of global query processing are consis¬ 
tent across most multidatabases. A user 
employs the global schema to submit a 
global query, or in the case of a multi¬ 
database language, the query itself con¬ 
tains all the information necessary for 
retrieving local data. The query is de¬ 
composed into a set of subqueries — 
one for each local DBMS that will be 
involved in query execution. The query 
optimizer creates an access strategy that 
specifies which local DBMSs are to be 


March 1992 


53 









involved, what each will do, how to com¬ 
bine the intermediate results, and where 
global processing will occur. Then the 
access strategy is executed. Global con¬ 
straints must be checked and enforced 
during query execution. Initial query 
processing usually occurs at the node 
where the query is submitted, while que¬ 
ry execution is distributed across the 
system. 

During global query execution, que¬ 
ries may be translated several times as 
they travel through the various system 
layers. Translations allow different lan¬ 
guages and representations at different 
layers and also resolve representation 
differences. 

Query decomposition and optimiza¬ 
tion in a distributed system have been 
studied in the distributed database en¬ 
vironment and several solutions to these 
problems are available. 1 Multidatabase 
systems must also handle interdatabase 
dependencies, manage global resourc¬ 
es, and support additional language fea¬ 
tures (for multidatabase languages). In¬ 
terdatabase dependencies may cause 
functions to cascade to many databases 
beyond the immediate scope of a query. 
The query processor must manage glo¬ 
bal resources, such as the global con¬ 
straints database, local workspaces, and 
software modules responsible for glo¬ 
bal processing. These resources are gen¬ 
erally distributed across the system. Fi¬ 
nally, multidatabase language systems 
provide many new language features 
that must be handled by the query pro¬ 
cessor. All these demands on the query 
processor must be handled in an effi¬ 
cient manner, despite its dynamic, dis¬ 
tributed nature and the lack of control 
over local DBMSs. 

Concurrency control. The traditional 
concept of a transaction as short-lived 
and atomic is unsuited to the multidata¬ 
base environment. Multidatabase trans¬ 
actions will typically involve multiple, 
separate local DBMSs and several lay¬ 
ers of data/query translations. 4 More im¬ 
portantly, local DBMSs have site auton¬ 
omy; so global control does not, in fact, 
include control of the actual data items. 
Multidatabase transactions are relative¬ 
ly long-lived and often nonatomic. 

Concurrency control schedules con¬ 
current-transaction data accesses to be 
serializable. However, this requires 
knowledge of all currently active trans¬ 
actions and the ability to control access 
to data items. A standard DBMS user 


interface does not normally provide in¬ 
formation about other users’ transac¬ 
tions or access to data item locks, time- 
stamps, etc. Moreover, different DBMSs 
may use different local concurrency 
control schemes. The global system has 
enough information to provide concur¬ 
rency control for global transactions, 
but it does not have information about 
local transactions. Therefore, it cannot 
provide total concurrency control. Con¬ 
sequently, many multidatabases, par¬ 
ticularly global schema multidatabases, 
restrict global information access to re¬ 
trieval only. Updates must be performed 
through the local DBMS interface on a 
node-by-node basis. 

Security. Distributed-system securi¬ 
ty is difficult. 5 Some of the problems 
include nonsecure communication links, 
varying levels of security at different 
nodes, and the large number of global 
user types to support. Multidatabases 
currently rely on underlying hardware 
and system software for most of their 
security requirements. Site autonomy 
provides some measure of local security 
because local DBAs can restrict the in¬ 
formation available to global users. The 
use of views for global users is also an 
important security measure. Accessing 
multiple systems typically means enter¬ 
ing multiple identification and authori¬ 
zation codes. Within a single system, 
accessing multiple data items can mean 
acquiring multiple authorizations. The 
global system must manage these multi¬ 
ple security requirements in an auto¬ 
mated fashion, while still respecting the 
intentions of the security mechanisms. 
Little work has been reported on the 
specific security requirements of the 
multidatabase environment. 

Local node requirements. Multidata¬ 
bases require global data structures and 
global software modules to implement 
global functions. Although site autono¬ 
my guarantees local DBMSs will be 
unchanged by joining a multidatabase, 
the local machine will have to share 
some of the global storage and process¬ 
ing requirements. Many multidatabas¬ 
es spread the load evenly over all partic¬ 
ipating sites. Others use server machines 
to perform most of the global functions, 
thus allowing the rest of the nodes to 
support less global function. This ar¬ 
rangement permits small or limited- 
capacity machines to participate in the 
multidatabase. 


Global data structures and global soft¬ 
ware functions vary among multidata¬ 
base systems. Common data structures 
include the global schema, auxiliary 
databases for global constraints, space 
for intermediate query results, and tem¬ 
porary workspaces for global functions. 
Common software functions include 
translation between local and global 
languages, transformation between lo¬ 
cal and global information representa¬ 
tions, query processing and optimiza¬ 
tion, and global system control. 

Design approaches 

There are two major approaches to 
designing a multidatabase system: glo¬ 
bal schemas and multidatabase languag¬ 
es. The global schema approach was 
used first in multidatabase design and 
continues to be a popular choice in many 
projects. The multidatabase language 
approach was inspired partly by the prob¬ 
lems inherent in the global schema ap¬ 
proach and partly by the simpler overall 
system architecture. 

Global schema. The global schema 
approach to multidatabases is a direct 
outgrowth of distributed databases. The 
global schema is just another layer, above 
the local external schemas, that pro¬ 
vides additional data independence. 
Consequently, some of the work in dis¬ 
tributed-database research is applica¬ 
ble, particularly in the area of global 
schema design. A major difference, how¬ 
ever, is that the global system cannot 
force local systems to conform to any 
sort of standard schema design (local 
schemas are developed independent¬ 
ly), nor can it control changes to the 
local schemas. Another major differ¬ 
ence is that a multidatabase global sche¬ 
ma may integrate local schemas from 
multiple data models. 

The global schema approach can make 
global access quite user friendly. Glo¬ 
bal users essentially see a single, albeit 
large, integrated database. The global 
interface is independent of all the het¬ 
erogeneity in local DBMSs and data 
representations. Because most global 
schema multidatabases employ the re¬ 
lational model, users get a familiar and 
intuitive paradigm for accessing the 
system. For specific users and applica¬ 
tions, views may be defined on top of 
the global schema to tailor the inter¬ 
face. The global schema is usually repli- 
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cated at each node for efficient user 
access. 

Global schema design. Global sche¬ 
ma design takes the independently de¬ 
veloped local schemas, resolves seman¬ 
tic and syntactic differences among them, 
and creates an integrated summary of 
all their information. This is also re¬ 
ferred to as view integration. Because 
of representation differences and inter¬ 
dependencies between data at different 
nodes, this process is more difficult than 
just taking a union of the input schemas. 

There are several common techniques 
for integrating multiple, distinct sche¬ 
mas. 6 ' 7 Similarities and conflicts between 
objects and relationships in separate 
schemas must be analyzed before they 
can be integrated. Some methodologies 
use special data models and design lan¬ 
guages with special constructs to re¬ 
solve representation differences. Gen¬ 
eralization hierarchies are often used to 
classify similar objects from different 
schemas. 8 Finally, there may be hun¬ 
dreds or thousands of schemas to inte¬ 
grate, and the size of the task compli¬ 
cates the design process. 

Despite the methodologies, algo¬ 
rithms, and heuristics that help auto¬ 
mate parts of the schema integration 
process, this process is still very human- 
labor intensive. Global DBAs must de¬ 
sign the global schema. These designers 
must have extensive knowledge of all 
the input schemas and global require¬ 
ments to decide how to integrate the 
inputs (that is, to decide which of the 
many possible global schemas to cre¬ 
ate). An optimal design for global re¬ 
quirements will likely conflict with some 
local optimizations, but the global DBA 
has no control over autonomous local 
nodes. Therefore, the global DBA must 
also understand all the local optimiza¬ 
tions and consider them when trying to 
create efficient global structures. The 
amount of global knowledge required is 
a major problem with the global schema 
approach. 

Global schema maintenance. A glo¬ 
bal schema can be a very large data 
object, thus making it difficult or impos¬ 
sible to replicate at nodes with limited 
storage facilities. The popularity of per¬ 
sonal computers and small DBMSs that 
might want to join the multidatabase 
system makes this an important prob¬ 
lem. Some systems get around this by 
only replicating the global schema at 


Language features 


The features described here are 
taken from MDSL, the multidata¬ 
base language for MRDSM (Mul- 
tics Relational Data Store Multi¬ 
ple). 10 A key aspect of MDSL is 
that query constructs remain valid 
while the dynamic environment 
changes (that is, the environment 
comprising the open local data¬ 
bases). At different points in the 
query execution, the operation 
may be applied to a single object, 
to multiple objects in different da¬ 
tabases, or to an empty set (all 
pertinent databases are closed). 
Results of the operation should be 
consistent and intuitive in all 
cases. 

The ability to define aliases and 
abbreviations for data item names 
is important for resolving name 
differences between databases. A 
name should be allowed to refer to 
multiple objects from different 
sources if the user thinks the ob¬ 
jects are semantically equivalent. 
Thus, an operation on a named 
object may actually cause multiple 
operations to occur. 

A user query might have to cre¬ 
ate temporary structures to hold 
intermediate results or new repre¬ 
sentations of information. A dy¬ 
namic attribute is a temporary at¬ 
tribute defined by a mapping from 
existing attributes. Dynamic at¬ 
tributes can be used to accom¬ 
plish transformations in data for¬ 
mat, to abstract attribute values 
from multiple sources into a single 
set of values, and to create a col¬ 
umn for joins with other relations. 


specified server nodes. However, this 
means queries cannot be processed at 
all query origin nodes. 

Global DBAs must also maintain the 
global schema in the face of arbitrary 
changes to local schemas. The literature 
is largely silent on how to do this. Chang¬ 
es to local schemas must be reflected in 
the global schema. The integration tech¬ 
niques used in global schema design 
and the types of changes in local data 
representations can complicate the map¬ 
ping of changes to the global schema. 
Local changes can force the DBA to 
reconsider many design decisions made 


during the initial integration process — 
with wide-reaching consequences. Again 
the DBA must have extensive global 
knowledge of all the input schemas, the 
global schema, and the initial design 
decisions. 

Multidatabase language. The multi¬ 
database language approach is an at¬ 
tempt to resolve some of the problems 
associated with global schemas, such as 
up-front knowledge required of DBAs, 
development time to create the global 
schema, significant maintenance require¬ 
ments, and processing/storage require¬ 
ments on local nodes. A multidatabase 
language system puts most of the inte¬ 
gration responsibility on users, but eas¬ 
es the burden of their tasks by giving 
them many support functions and by 
providing more control over the infor¬ 
mation. Examples of such functions are 
included in the sidebar on language fea¬ 
tures. Most multidatabase languages are 
relational, similar to SQL in the stan¬ 
dard capabilities, but extend the func¬ 
tion significantly. Witold Litwin has ar¬ 
gued persuasively for multidatabase 
languages and performed significant 
research in this area. 910 

Many of the language extensions be¬ 
yond standard database capabilities are 
involved with manipulating data repre¬ 
sentations. Since representation differ¬ 
ences exist when the user submits a 
query, the language must be capable of 
transforming source information into 
the representations most useful to the 
user. It is particularly desirable in this 
context to make the language nonproc¬ 
edural. The multidatabase system should 
be capable of making some implicit de¬ 
cisions in interpreting what the user 
wants to accomplish and providing many 
functions by default. 

Multidatabase language system users 
must have a means to display what in¬ 
formation is available from various 
sources. The user is assumed to have 
well-defined ideas about what informa¬ 
tion is required and where it probably 
resides. Otherwise, the magnitude of 
the information available globally will 
make finding necessary data an over¬ 
whelming task. The language should 
provide the ability to limit the scope of 
a query to the pertinent local databases. 

In summary, the multidatabase lan¬ 
guage approach shifts the burden of 
integration from global DBAs to users 
and local DBAs. Users must have some 
global knowledge of representation dif- 
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Table 2. Global schema multidatabase projects. 


System Name/Organization 

Stage of 

Global 

Global 

System Emphases or 

Development 

Data Model 

Updates? 

Key Features 

ADDS(Amoco Distributed Database System) 1 

Limited 

Extended 

In near 

Comprehensive function, powerful 

Amoco Research Center 

prototype 

relational 

future 

user interface, global constraints 

Dataplex 2 

General Motors Research 

Limited 

prototype 

Relational 

Yes 

Query decomposition and 
optimization 

DQS (Distributed Query System) 3 

CRAI, Italy 

Prototype 

Relational 

No 

Query optimization 

EDDS (Experimental Distributed Database 
System) 4 

University of Ulster 

Prototype 

Relational 

Yes 

Small machines can join system 

HD-DBMS (Heterogeneous Distributed- 

Research 

Entity- 


Global access path information, 

DBMS) 5 

UCLA 


relationship 


external views in multiple data 
models 

JDDBS (Japanese Distributed Database 
System) 6 

Japan Information Processing 

Development Center 

Limited 

prototype 

Relational 

Yes 

Based on a broadcast network 


Mermaid 7 

Unisys 

Prototype 

Relational 


Query optimization 

Multibase 8 

Limited 

Functional 

No 

Comprehensive function 

Computer Corporation of America 

prototype 



MultiStar 9 

Consortium headed by CRAI, Italy 

Prototype 

Relational 

No 

Query processing, ability to link to 
other multidatabases 

NDMS (Network Data Management System) 10 
CRAI, Italy 

Prototype 

Relational 

Yes 

Query optimization 

Preci* 11 

Limited 

Relational 

Yes 

Replicated data, nodes can support 

University of Aberdeen 

prototype 



different levels of global function 

Proteus 12 

Prototype 

Abstracted 

No 

Star network topology, multiple 

British universities 


conceptual 


global access languages 

Scoop 13 

Universities of Paris and Turin 

Research 

Entity- 

relationship 


Study mapping algorithms 
between system levels 

Sirius-Delta 14 

Limited 

Relational 


Translations to/from pivot system 

INRIA, France 

prototype 



(global data model/language) 

Unibase 15 

Institute for Scientific, Technical, and 

Economic Information, Poland 

Research 

Relational 


Global constraints 


XNDM (Experimental Network Data 

Limited 

Relational 

Yes 

Data translations, use of server 

Manager) 16 

National Bureau of Standards 

prototype 



nodes for global processing 


ferences and data sources, but only about 
the information actually used. Multida¬ 
tabase language systems trade a level of 
data independence (the global schema 
hides duplication, heterogeneity, and 
location information) for a more dy¬ 
namic system and greater control over 
system information. 
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Review of existing 
projects 

Tables 2 through 5 review most of 
the current multidatabase projects re¬ 
ported in the literature. These projects 
come from a variety of countries and 


institutions. Some are mainly research 
vehicles to study specific problem ar¬ 
eas; others are full commercial systems. 
The range of organizations and the 
number of projects indicate the impor¬ 
tance of this field. The tables compare 
high-level details and include a prima¬ 
ry reference for each project. The re- 
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ported functional content for each 
project is based on the reference mate¬ 
rial. 

Blank table entries mean the infor¬ 
mation was not apparent from the ref¬ 
erence. “In the near future” indicates 
that a function has been designed but its 
implementation is not yet complete. 


Several stages of project development 
are indicated: 

• Research — a functional system has 
not yet been implemented; 

• Limited prototype — the system has 
been implemented, but is not fully 
functional; 


• Prototype — a full system has been 
implemented within the organiza¬ 
tion; and 

• Commercial — the system has been 
implemented and is available for 
purchase. 

The column for system emphases and 
key features presents important or un¬ 
usual features of the system. It does not 
give a comprehensive picture of avail¬ 
able system functions. 

The majority of systems under study 
are global schema multidatabases. The 
close ties to distributed databases allow 
some synergy in solving related issues 
in the two fields. The single data-source 
user paradigm is also appealing. How¬ 
ever, problems of size and complexity 
make global schema multidatabases 
impractical for large distributed systems. 
Since the trend today is toward more 
interconnection (that is, toward larger 
systems), multidatabase language sys¬ 
tems —the other maj or design approach 
— seem more practical for many future 
requirements. 

Multidatabase language systems have 
no constraints on system size, but the 
trade-off for achieving this is a multiple 
data-source user paradigm and a more 
complex user interface. The access lan¬ 
guage has more features, and users must 
have more knowledge about data loca¬ 
tions and local representations. A testi¬ 
mony to the effectiveness of multidata¬ 
base language systems relative to global 
schema multidatabases is the fact that 
homogeneous multidatabase language 
systems are the first class of multidata¬ 
bases to produce commercial products, 
albeit with limited functions. 

T here are a number of open prob¬ 
lems to solve to make multi¬ 
database systems more useful 
and efficient. First, global system re¬ 
quirements should not be equally dis¬ 
tributed among all nodes. Today’s dis¬ 
tributed systems contain a variety of 
machine types and sizes, and small ma¬ 
chines should be able to join the system 
with minimal local overhead required. 
Some existing multidatabase systems 
recognize this need. 

In addition, multidatabase systems 
should make better use of powerful serv¬ 
er nodes to perform the bulk of global 
processing. The large processing require¬ 
ments and heterogeneous nature of 
multidatabase systems seem ideally suit¬ 
ed to incorporating specialized data- 
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Table 3. Federated database projects. 


System Name/Organization 

Stage of 
Development 

Global 

Data Model 

Global 

Updates? System Emphases or Key Features 

Heimbigner 1 

University of Colorado 

Limited 

prototype 

Object 

oriented 

Yes 

Language support for data 
transformations, negotiation 
protocol for input schema creation 

Ingres/Star 2 

Relational Technology, Inc. 

Commercial 

Relational 

In near 
future 

Can define multiple import 
schemas at a node 

Superdatabases 3 

Columbia University 

Research 


Yes 

Hierarchical system structure, 
concurrency control 
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Table 4. Multidatabase language system projects. 


System Name/Organization 

Stage of 
Development 

Global 

Data Model 

Global 

Updates? 

System Emphases or Key Features 

Calida 1 

GTE Research Labs 

Prototype 

Relational 

Yes 

Query optimization, implicit joins 

Hetero 2 

Felipe Carino, California 

Prototype 

Extended 

relational 

Yes 

Powerful user interface 

Linda 3 

Technical Research Center 
of Finland 

Limited 

prototype 

Relational 


Close to being an interoperable 
system rather than a multidatabase 

MRDSM (Multics Relational 

Data Store Multiple) 4 

INRIA, France 

Prototype 

Relational 

Yes 

Comprehensive function, 
many language features, global 
constraints 

Odu 5 

University of Wales 

Limited 

prototype 

Entity- 

relationship 

No 

Small machines can join systems 

SWIFT (Society for Worldwide Research 

Interbank Financial Telecommunication) 6 

SWIFT, Europe 

Relational 


Transaction structure and 
processing 

VIP-MDBS (Vienna Integrated 
Prolog-Multidatabase System) 7 
Vienna Technical University 

Prototype 

Relational 


Global language is Prolog 
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Table 5. Homogeneous multidatabase language system projects. 


System Name/Organization 

Stage of 
Development 

Global 

Data Model 

Global 

Updates? 

System Emphases or Key Features 

Empress 1 

Rhodius Inc. 

Commercial 

Relational 

Yes 

Limited global language function 

Sybase 1 

Sybase, Inc. 

Commercial 

Relational 


Limited global language function 

System R’ 2 

IBM 

Prototype 

Relational 

Yes 

Query optimization 
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I base machines. 11 Adding a database 
I machine to the underlying distributed 
I system could dramatically enhance per- 
I formance if the multidatabase system 
I could dynamically redistribute global 
I processing to make use of the added 
I capability. 

Another problem is the lack of sup- 
I port for identifying specific data in a 
I system, given the possible huge amounts 
I of data available globally. Multidata- 
I base systems provide location indepen- 
I dence for data, but only after the user 
I has precisely identified the data to ac- 
I cess. Discovering the precise identifiers 
I for desired data can be a problem if the 
[ user does not already know them. Most 
I existing multidatabase systems provide 
users with the ability to scan the avail- 
[ able data sequentially, but this approach 
I is impractical for large systems. If a user 
I cannot easily find the data that he or she 
I wants to access, then the system has 
I failed to provide global information 
[ access. Multidatabase systems should 
I provide some navigational aids to help 
the user find the desired data. One pos¬ 
sible approach is to provide a summa¬ 
rized view of the global information 
I available. 12 A summary data represen¬ 
tation would be more compact, there¬ 
fore easier to search. Another approach 
would be to add intelligence to the sys- 
| tem so it could identify specific data 
when given imprecise identifiers. 12 

Related to the problem of searching 
I large amounts of data is the problem of 
identifying semantically equivalent data 
in different local databases. Because of 
the large amounts of data involved, 
i searching for all semantically identical 
entities can be a lengthy process. Most 


existing multidatabase systems provide 
functions for mapping entities to a com¬ 
mon data representation after semantic 
equivalence has been established, but 
identifying semantic equivalence is an 
open problem. Again, a summary rep¬ 
resentation of system data could help 
by giving semantically equivalent enti¬ 
ties a common representation at a more 
abstract level. 12 ■ 
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The Stanford Dash 
Multiprocessor 


Daniel Lenoski, James Laudon, Kourosh Gharachorloo, 
Wolf-Dietrich Weber, Anoop Gupta, John Hennessy, 
Mark Horowitz, and Monica S. Lam 
Stanford University 


Directory-based 
cache coherence gives 
Dash the ease-of-use 
of shared-memory 
architectures while 
maintaining the 
scalability of 
message-passing 
machines. 


T he Computer Systems Laboratory at Stanford University is developing a 
shared-memory multiprocessor called Dash (an abbreviation for Direc¬ 
tory Architecture for Shared Memory). The fundamental premise behind 
the architecture is that it is possible to build a scalable high-performance machine 
with a single address space and coherent caches. 

The Dash architecture is scalable in that it achieves linear or near-linear 
performance growth as the number of processors increases from a few to a few 
thousand. This performance results from distributing the memory among process¬ 
ing nodes and using a network with scalable bandwidth to connect the nodes. The 
architecture allows shared data to be cached, thereby significantly reducing the 
latency of memory accesses and yielding higher processor utilization and higher 
overall performance. A distributed directory-based protocol provides cache co¬ 
herence without compromising scalability. 

The Dash prototype system is the first operational machine to include a scalable 
cache-coherence mechanism. The prototype incorporates up to 64 high-perfor¬ 
mance RISC microprocessors to yield performance up to 1.6 billion instructions 
per second and 600 million scalar floating point operations per second. The design 
of the prototype has provided deeper insight into the architectural and implemen¬ 
tation challenges that arise in a large-scale machine with a single address space. 
The prototype will also serve as a platform for studying real applications and 
software on a large parallel system. 

This article begins by describing the overall goals for Dash, the major features 
of the architecture, and the methods for achieving scalability. Next, we describe the 
directory-based coherence protocol in detail. We then provide an overview of the 
prototype machine and the corresponding software support, followed by some 
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preliminary performance numbers. The 
article concludes with a discussion of 
related work and the current status of 
the Dash hardware and software. 

Dash project overview 

The overall goal of the Dash project 
is to investigate highly parallel architec¬ 
tures. For these architectures to achieve 
widespread use, they must run a variety 
of applications efficiently without im¬ 
posing excessive programming difficul¬ 
ty. To achieve both high performance 
and wide applicability, we believe a par¬ 
allel architecture must provide scalabil¬ 
ity to support hundreds to thousands of 
processors, high-performance individ¬ 
ual processors, and a single shared ad¬ 
dress space. 

The gap between the computing pow¬ 
er of microprocessors and that of the 
largest supercomputers is shrinking, 
while the price/performance advantage 
of microprocessors is increasing. This 
clearly points to using microprocessors 
as the compute engines in a multipro¬ 
cessor. The challenge lies in building a 
machine that can scale up its perfor¬ 
mance while maintaining the initial price/ 
performance advantage of the individu¬ 
al processors. Scalability allows a paral¬ 
lel architecture to leverage commodity 
microprocessors and small-scale multi¬ 
processors to build larger scale machines. 
These larger machines offer substan¬ 
tially higher performance, which pro¬ 
vides the impetus for programmers to 
port their sequential applications to par¬ 
allel architectures instead of waiting for 
the next higher performance uniproces¬ 
sor. 

High-performance processors are 
important to achieve both high total 
system performance and general appli¬ 
cability. Using the fastest microproces¬ 
sors reduces the impact of limited or 
uneven parallelism inherent in some 
applications. It also allows a wider set of 
applications to exhibit acceptable per¬ 
formance with less effort from the pro¬ 
grammer. 

A single address space enhances the 
programmability of a parallel machine 
by reducing the problems of data parti¬ 
tioning and dynamic load distribution, 
two of the toughest problems in pro¬ 
gramming parallel machines. The shared 
address space also improves support for 
automatically parallelizing compilers, 
standard operating systems, multipro- 


The Dash team 

Many graduate students and fac¬ 
ulty members contributed to the 
Dash project. The PhD students 
are Daniel Lenoski and James Lau- 
don (Dash architecture and hard¬ 
ware design); Kourosh Gharachor- 
too (Dash architecture and 
consistency models); Wolf-Dietrich 
Weber (Dash simulator and scal¬ 
able directories); Truman Joe 
(Dash hardware and protocol verifi¬ 
cation tools); Luis Stevens (operat¬ 
ing system); Helen Davis and Ste¬ 
phen Goldschmidt (trace 
generation tools, synchronization 
patterns, locality studies); Todd 
Mowry (evaluation of prefetch oper¬ 
ations); Aaron Goldberg and Marg¬ 
aret Martonosi (performance de¬ 
bugging tools); Tom Chanak (mesh 
routing chip design); Richard Simo- 
ni (synthetic load generator and di¬ 
rectory studies); Josep Torrellas 
(sharing patterns in applications); 
Edward Rothberg, Jaswinder Pal 
Singh, and Larry Soule (applica¬ 
tions and algorithm development). 
Staff research engineer David Na- 
kahira contributed to the hardware 
design. 

The faculty associated with the 
project are Anoop Gupta, John 
Hennessy, Mark Horowitz, and 
Monica Lam. 


gramming, and incremental tuning of 
parallel applications — features that 
make a single-address-space machine 
much easier to use than a message-pass¬ 
ing machine. 

Caching of memory, including shared 
writable data, allows multiprocessors 
with a single address space to achieve 
high performance through reduced 
memory latency. Unfortunately, cach¬ 
ing shared data introduces the problem 
of cache coherence (see the sidebar and 
accompanying figure). 

While hardware support for cache 
coherence has its costs, it also offers 
many benefits. Without hardware sup¬ 
port, the responsibility for coherence 
falls to the user or the compiler. Expos¬ 
ing the issue of coherence to the user 
would lead to a complex programming 
model, where users might well avoid 
caching to ease the programming bur¬ 


den. Handling the coherence problem 
in the compiler is attractive, but cur¬ 
rently cannot be done in a way that is 
competitive with hardware. With hard- 
ware-supported cache coherence, the 
compiler can aggressively optimize pro¬ 
grams to reduce latency without having 
to rely purely on a conservative static 
dependence analysis. 

The major problem with existing 
cache-coherent shared-address ma¬ 
chines is that they have not demonstrat¬ 
ed the ability to scale effectively be¬ 
yond a few high-performance processors. 
To date, only message-passing machines 
have shown this ability. We believe that 
using a directory-based coherence mech¬ 
anism will permit single-address-space 
machines to scale as well as message¬ 
passing machines, while providing a 
more flexible and general programming 
model. 

Dash system 
organization 

Most existing multiprocessors with 
cache coherence rely on snooping to 
maintain coherence. Unfortunately, 
snooping schemes distribute the infor¬ 
mation about which processors are cach¬ 
ing which data items among the caches. 
Thus, straightforward snooping schemes 
require that all caches see every memo¬ 
ry request from every processor. This 
inherently limits the scalability of these 
machines because the common bus and 
the individual processor caches eventu¬ 
ally saturate. With today’s high-perfor¬ 
mance RISC processors this saturation 
can occur with just a few processors. 

Directory structures avoid the seal- 
ability problems of snoopy schemes by 
removing the need to broadcast every 
memory request to all processor caches. 
The directory maintains pointers to the 
processor caches holding a copy of each 
memory block. Only the caches with 
copies can be affected by an access to 
the memory block, and only those cach¬ 
es need be notified of the access. Thus, 
the processor caches and interconnect 
will not saturate due to coherence re¬ 
quests. Furthermore, directory-based co¬ 
herence is not dependent on any specif¬ 
ic interconnection network like the bus 
used by most snooping schemes. The 
same scalable, low-latency networks 
such as Omega networks or k -nary n- 
cubes used by non-cache-coherent and 
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Cache coherence 

Cache-coherence problems can arise in shared-memory 
multiprocessors when more than one processor cache holds 
a copy of a data item (a). Upon a write, these copies must be 
updated or invalidated (b). Most systems use invalidation 
since this allows the writing processor to gain exclusive ac¬ 
cess to the cache line and complete further writes into the 
cache line without generating external traffic (c). This further 
complicates coherence since this dirty cache must respond 
instead of memory on subsequent accesses by other proces¬ 
sors (d). 

Small-scale multiprocessors frequently use a snoopy 
cache-coherence protocol, 1 which relies on all caches moni¬ 
toring the common bus that connects the processors to 
memory. This monitoring allows caches to independently de¬ 
termine when to invalidate cache lines (b), and when to in¬ 
tervene because they contain the most up-to-date copy of a 
given location (d). Snoopy schemes do not scale to a large 
number of processors because the common bus or individual 
processor caches eventually saturate, since they must pro¬ 
cess every memory request from every processor. 

The directory relieves the processor caches from snooping 
on memory requests by keeping track of which caches hold 
each memory block. A simple directory structure first pro¬ 
posed by Censier and Feautrier 2 has one directory entry per 
block of memory (e). Each entry contains one presence bit 
per processor cache. In addition, a state bit indicates wheth¬ 
er the block is uncached, shared in multiple caches, or held 
exclusively by one cache (that is, whether the block is dirty). 
Using the state and presence bits, the memory can tell which 
caches need to be invalidated when a location is written (b). 
Likewise, the directory indicates whether memory’s copy of 
the block is up to date or which cache holds the most recent 
copy (d). If the memory and directory are partitioned into in¬ 
dependent units and connected to the processors by a scal¬ 
able interconnect, the memory system can provide scalable 
memory bandwidth. 


References 

1. J. Archibald and J.-L. Baer, “Cache Coherence Protocols: Evalu¬ 
ation Using a Multiprocessor Simulation Model,” ACM Trans. 
Computer Systems, Vol. 4, No, 4, Nov. 1986, pp. 273-298. 

2. L. Censier and P. Feautrier, “A New Solution to Coherence 
Problems in Multicache Systems,” IEEE Trans. Computers, Vol. 
C-27, No. 12, Dec. 1978, pp. 1,112-1,118. 
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message-passing machines can be em¬ 
ployed. 

The concept of directory-based cache 
coherence is not new. It was first pro¬ 
posed in the late 1970s. However, the 


original directory structures were not 
scalable because they used a central¬ 
ized directory that quickly became a 
bottleneck. The Dash architecture over¬ 
comes this limitation by partitioning and 


distributing the directory and main 
memory, and by using a new coherence 
protocol that can suitably exploit dis¬ 
tributed directories. In addition, Dash 
provides several other mechanisms to 


March 1992 


65 







































































































Figure 1. The Dash architecture consists of a set of clus¬ 
ters connected by a general interconnection network. Di¬ 
rectory memory contains pointers to the clusters currently 
caching each memory line. 


reduce and hide the latency 
of memory operations. 

Figure 1 shows Dash’s 
high-level organization. The 
architecture consists of a 
number of processing nodes 
connected through directo¬ 
ry controllers to a low-laten¬ 
cy interconnection network. 

Each processing node, 
cluster, consists of a small 
number of high-performance 
processors and a portion of 
the shared memory intercon¬ 
nected by a bus. Multipro¬ 
cessing within the cluster can 
be viewed either as increas¬ 
ing the power of each pro¬ 
cessing node or as reducing 
the cost of the directory and 
network interface by amor¬ 
tizing it over a larger num¬ 
ber of processors. 

Distributing memory with 
the processors is essential be¬ 
cause it allows the system to 
exploit locality. All private 
data and code references, 
along with some of the shared 
references, cani be made lo¬ 
cal to the cluster. These references avoid 
the longer latency of remote references 
and reduce the bandwidth demands on 
the global interconnect. Except for the 
directory memory, the resulting system 


architecture is similar to many scalable 
message-passing machines. While not 
optimized to do so, Dash could emulate 
such machines with reasonable effi¬ 
ciency. 


Scalability 
of the Dash 
approach 

We have outlined why we 
believe a single-address- 
space machine with cache 
coherence holds the most 
promise for delivering scal¬ 
able performance to a wide 
range of applications. Here, 
we address the more de¬ 
tailed issues in scaling such 
a directory-based system. 
The three primary issues are 
ensuring that the system pro- 
vides scalable memory 
bandwidth, that the costs 
scale reasonably, and that 
mechanisms are provided to 
deal with large memory la¬ 
tencies. 

Scalability in a multipro¬ 
cessor requires the total 
memory bandwidth to scale 
linearly with the number of 
processors. Dash provides 
scalable bandwidth to data 
objects residing in local memory by dis¬ 
tributing the physical memory among 
the clusters. For data accesses that must 
be serviced remotely, Dash uses a scal¬ 
able interconnection network. Support 



Figure 2. Cache invalidation patterns for MP3D (a) and PThor (b). MP3D uses a particle-based simulation technique to 
determine the structure of shock waves caused by objects flying at high speed in the upper atmosphere. PThor is a paral¬ 
lel logic simulator based on the Chandy-Misra algorithm. 
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of coherent caches could potentially 
compromise the scalability of the net¬ 
work by requiring frequent broadcast 
messages. The use of directories, how¬ 
ever, removes the need for such broad¬ 
casts and the coherence traffic consists 
only of point-to-point messages to clus¬ 
ters that are caching that location. Since 
these clusters must have originally 
fetched the data, the coherence traffic 
will be within some small constant fac¬ 
tor of the original data traffic. In fact, 
since each cached block is usually ref¬ 
erenced several times before being in¬ 
validated, caching normally reduces 
overall global traffic significantly. 

This discussion of scalability assumes 
that the accesses are uniformly distrib¬ 
uted across the machine. Unfortunate¬ 
ly, the uniform access assumption does 
not always hold for highly contended 
synchronization objects and for heavily 
shared data objects. The resulting hot 
spots — concentrated accesses to data 
from the memory of a single cluster 
over a short duration of time — can 
significantly reduce the memory and 
network throughput. The reduction oc¬ 
curs because the distribution of resourc¬ 
es is not exploited as it is under uniform 
access patterns. 

To address hot spots, Dash relies on 
a combination of hardware and soft¬ 
ware techniques. For example, Dash 
provides special extensions to the di- 
rectory-based protocol to handle syn¬ 
chronization references such as queue- 
based locks (discussed further in the 
section, “Support for synchronization”). 
Furthermore, since Dash allows cach¬ 
ing of shared writable data, it avoids 
many of the data hot spots that occur in 
other parallel machines that do not per¬ 
mit such caching. For hot spots that 
cannot be mitigated by caching, some 
can be removed by the coherence pro¬ 
tocol extensions discussed in the sec¬ 
tion, “Update and deliver operations,” 
while others can only be removed by 
restructuring at the software level. For 
example, when using a primitive such 
as a barrier, it is possible for software to 
avoid hot spots by gathering and releas¬ 
ing processors through a tree of memo¬ 
ry locations. 

Regarding system costs, a major seal- 
ability concern unique to Dash-like ma¬ 
chines is the amount of directory mem¬ 
ory required. If the physical memory in 
the machine grows proportionally with 
the number of processing nodes, then 
using a bit-vector to keep track of all 


clusters caching a memory block does 
not scale well. The total amount of di¬ 
rectory memory needed is P 2 x MIL 
megabits, where P is the number of 
clusters, M is the megabits of memory 
per cluster, and L is the cache-line size 
in bits. Thus, the fraction of memory 
devoted to keeping directory informa¬ 
tion grows as PIL. Depending on the 
machine size, this growth may or may 
not be tolerable. For example, consider 
a machine that contains up to 32 clus¬ 
ters of eight processors each and has a 
cache (memory) line size of 32 bytes. 
For this machine, the overhead for di¬ 
rectory memory is only 12.5 percent of 
physical memory as the system scales 
from eight to 256 processors. This is 
comparable with the overhead of sup¬ 
porting an error-correcting code on 
memory. 

For larger machines, where the over¬ 
head would become intolerable, sever¬ 
al alternatives exist. First, we can take 
advantage of the fact that at any given 
time a memory block is usually cached 
by a very small number of processors. 
For example, Figure 2 shows the num¬ 
ber of invalidations generated by two 
applications run on a simulated 32-pro¬ 
cessor machine. These graphs show that 
most writes cause invalidations to only 
a few caches. (We have obtained similar 
results for a large number of applica¬ 
tions.) Consequently, it is possible to 
replace the complete directory bit-vec¬ 
tor by a small number of pointers and to 
use a limited broadcast of invalidations 
in the unusual case when the number of 
pointers is too small. Second, we can 
take advantage of the fact that most 
main memory blocks will not be present 
in any processor’s cache, and thus there 
is no need to provide a dedicated direc¬ 
tory entry for every memory block. Stud¬ 
ies 1 - 2 have shown that a small directory 
cache performs almost as well as a full 
directory. These two techniques can be 
combined to support machines with 
thousands of processors without undue 
overhead from directory memory. 

The issue of memory access latency 
also becomes more prominent as an 
architecture is scaled to a larger num¬ 
ber of nodes. There are two comple¬ 
mentary approaches for managing la¬ 
tency: methods that reduce latency and 
mechanisms that help tolerate it. Dash 
uses both approaches, though our main 
focus has been to reduce latency as much 
as possible. Although latency tolerating 
techniques are important, they often 


require additional application parallel¬ 
ism to be effective. 

Hardware-coherent caches provide the 
primary latency reduction mechanism 
in Dash. Caching shared data signifi¬ 
cantly reduces the average latency for 
remote accesses because of the spatial 
and temporal locality of memory ac¬ 
cesses. For references not satisfied by 
the cache, the coherence protocol at¬ 
tempts to minimize latency, as shown in 
the next section. Furthermore, as previ¬ 
ously mentioned, we can reduce latency 
by allocating data to memory close to 
the processors that use it. While average 
memory latency is reduced, references 
that correspond to interprocessor com¬ 
munication cannot avoid the inherent 
latencies of a large machine. In Dash, 
the latency for these accesses is addressed 
by a variety of latency hiding mecha¬ 
nisms. These mechanisms range from 
support of a relaxed memory consisten¬ 
cy model to support of nonblocking 
prefetch operations. These operations 
are detailed in the sections on “Mem¬ 
ory consistency” and “Prefetch opera¬ 
tions.” 

We also expect software to play a 
critical role in achieving good perfor¬ 
mance on a highly parallel machine. Ob¬ 
viously, applications need to exhibit good 
parallelism to exploit the rich computa¬ 
tional resources of a large machine. In 
addition, applications, compilers, and 
operating systems need to exploit cache 
and memory locality together with la¬ 
tency hiding techniques to achieve high 
processor utilization. Applications still 
benefit from the single address space, 
however, because only performance-crit¬ 
ical code needs to be tuned to the sys¬ 
tem. Other code can assume a simple 
uniform memory model. 

The Dash cache- 
coherence protocol 

Within the Dash system organization, 
there is still a great deal of freedom in 
selecting the specific cache-coherence 
protocol. This section explains the basic 
coherence protocol that Dash uses for 
normal read and write operations, then 
outlines the resulting memory con¬ 
sistency model visible to the program¬ 
mer and compiler. Finally, it details ex¬ 
tensions to the protocol that support 
latency hiding and efficient synchroni¬ 
zation. 
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Memory hierarchy. Dash implements 
an invalidation-based cache-coherence 
protocol. A memory location may be in 
one of three states: 

• uncached — not cached by any clus¬ 
ter; 

• shared — in an unmodified state in 
the caches of one or more clusters; 

• dirty — modified in a single cache of 
some cluster. 

The directory keeps the summary infor¬ 
mation for each memory block, specify¬ 
ing its state and the clusters that are 
caching it. 

The Dash memory system can be log¬ 
ically broken into four levels of hierar¬ 
chy, as illustrated in Figure 3. The first 
level is the processor’s cache. This cache 
is designed to match the processor speed 
and support snooping from the bus. A 
request that cannot be serviced by the 
processor’s cache is sent to the second 
level in the hierarchy, the local cluster. 
This level includes the other proces¬ 
sors’ caches within the requesting pro¬ 
cessor’s cluster. If the data is locally 
cached, the request can be serviced with¬ 
in the cluster. Otherwise, the request is 
sent to the home cluster level. The home 
level consists of the cluster that con¬ 
tains the directory and physical memo¬ 
ry for a given memory address. For many 
accesses (for example, most private data 
references), the local and home cluster 
are the same, and the hierarchy collaps¬ 
es to three levels. In general, however, a 
request will travel through the inter¬ 
connection network to the home clus¬ 
ter. The home cluster can usually satisfy 
the request immediately, but if the di¬ 
rectory entry is in a dirty state, or in 
shared state when the requesting pro¬ 
cessor requests exclusive access, the 
fourth level must also be accessed. The 
remote cluster level for a memory block 
consists of the clusters marked by the 
directory as holding a copy of the block. 

To illustrate the directory protocol, 
first consider how a processor read 
traverses the memory hierarchy: 

• Processor level — If the requested 
location is present in the processor’s 
cache, the cache simply supplies the 
data. Otherwise, the request goes to the 
local cluster level. 

•Local cluster level — If the data 
resides within one of the other caches 
within the local cluster, the data is sup- 



Figure 3. Memory hierarchy of Dash. 


plied by that cache and no state change 
is required at the directory level. If the 
request must be sent beyond the local 
cluster level, it goes first to the home 
cluster corresponding to that address. 

• Home cluster level —The home clus¬ 
ter examines the directory state of the 
memory location while simultaneously 
fetching the block from main memory. 
If the block is clean, the data is sent to 
the requester and the directory is up¬ 
dated to show sharing by the requester. 
If the location is dirty, the request is 
forwarded to the remote cluster indi¬ 
cated by the directory. 

•Remote cluster level — The dirty 
cluster replies with a shared copy of the 
data, which is sent directly to the re¬ 
quester. In addition, a sharing write¬ 
back message is sent to the home level 
to update main memory and change the 
directory state to indicate that the re¬ 
questing and remote cluster now have 
shared copies of the data. Having the 
dirty cluster respond directly to the re¬ 
quester, as opposed to routing it through 
the home, reduces the latency seen by 
the requesting processor. 

Now consider the sequence of opera¬ 
tions that occurs when a location is writ¬ 
ten: 

• Processor level — If the location is 
dirty in the writing processor’s cache, 
the write can complete immediately. 
Otherwise, a read-exclusive request is 


issued on the local cluster’s bus to ob¬ 
tain exclusive ownership of the line and 
retrieve the remaining portion of the 
cache line. 

• Local cluster level — If one of the 
caches within the cluster already owns 
the cache line, then the read-exclusive 
request is serviced at the local level by a 
cache-to-cache transfer. This allows pro¬ 
cessors within a cluster to alternately 
modify the same memory block without 
any intercluster interaction. If no local 
cache owns the block, then a read-ex¬ 
clusive request is sent to the home clus¬ 
ter. 

• Home cluster level —The home clus¬ 
ter can immediately satisfy an owner¬ 
ship request for a location that is in the 
uncached or shared state. In addition, if 
a block is in the shared state, then all 
cached copies must be invalidated. The 
directory indicates the clusters that have 
the block cached. Invalidation requests 
are sent to these clusters while the home 
concurrently sends an exclusive data 
reply to the requesting cluster. If the 
directory indicates that the block is dirty, 
then the read-exclusive request must be 
forwarded to the dirty cluster, as in the 
case of a read. 

• Remote cluster level — If the direc¬ 
tory had indicated that the memory block 
was shared, then the remote clusters 
receive an invalidation request to elim¬ 
inate their shared copy. Upon receiving 
the invalidation, the remote clusters send 
an acknowledgment to the requesting 
cluster. If the directory had indicated a 
dirty state, then the dirty cluster re¬ 
ceives a read-exclusive request. As in 
the case of the read, the remote cluster 
responds directly to the requesting clus¬ 
ter and sends a dirty-transfer message 
to the home indicating that the request¬ 
ing cluster now holds the block exclu¬ 
sively. 

When the writing cluster receives all 
the invalidation acknowledgments or 
the reply from the home or dirty cluster, 
it is guaranteed that all copies of the old 
data have been purged from the system. 
If the processor delays completing the 
write until all acknowledgments are re¬ 
ceived, then the new write value will 
become available to all other proces¬ 
sors at the same time. However, invali¬ 
dations involve round-trip messages to 
multiple clusters, resulting in potential¬ 
ly long delays. Higher processor utiliza¬ 
tion can be obtained by allowing the 
write to proceed immediately after the 
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ownership reply is received from the 
home. Unfortunately, this may lead to 
inconsistencies with the memory model 
assumed by the programmer. The next 
section describes how Dash relaxes the 
constraints on memory request order¬ 
ing, while still providing a reasonable 
programming model to the user. 

Memory consistency. The memory 
consistency model supported by an ar¬ 
chitecture directly affects the amount 
of buffering and pipelining that can take 
place among memory requests. In addi¬ 
tion, it has a direct effect on the com¬ 
plexity of the programming model pre¬ 
sented to the user. The goal in Dash is to 
provide substantial freedom in the or¬ 
dering among memory requests, while 
still providing a reasonable program¬ 
ming model to the user. 

At one end of the consistency spec¬ 
trum is the sequential consistency mod¬ 
el, 3 which requires execution of the par¬ 
allel program to appear as an interleaving 
of the execution of the parallel process¬ 
es on a sequential machine. Sequential 
consistency can be guaranteed by re¬ 
quiring a processor to complete one 
memory request before it issues the next 
request. 4 Sequential consistency, while 
conceptually appealing, imposes a large 
performance penalty on memory ac¬ 
cesses. For many applications, such a 
model is too strict, and one can make do 
with a weaker notion of consistency. 

As an example, consider the case of a 
processor updating a data structure with¬ 
in a critical section. If updating the struc¬ 
ture requires several writes, each write 
in a sequentially consistent system will 
stall the processor until all other cached 
copies of that location have been inval¬ 
idated. But these stalls are unnecessary 
as the programmer has already made 
sure that no other process can rely on 
the consistency of that data structure 
until the critical section is exited. If the 
synchronization points can be identi¬ 
fied, then the memory need only be 
consistent at those points. In particular, 
Dash supports the use of the release 
consistency model, 5 which only requires 
the operations to have completed be¬ 
fore a critical section is released (that is, 
a lock is unlocked). 

Such a scheme has two advantages. 
First, it provides the user with a reason¬ 
able programming model, since the pro¬ 
grammer is assured that when the criti¬ 
cal section is exited, all other processors 
will have a consistent view of the mod- 


Release consistency 
provides a 10- to 40- 
percent increase in 
performance over 
sequential consistency. 


ified data structure. Second, it permits 
reads to bypass writes and the invalida¬ 
tions of different write operations to 
overlap, resulting in lower latencies for 
accesses and higher overall performance. 
Detailed simulation studies for proces¬ 
sors with blocking reads have shown 
that release consistency provides a 10- 
to 40-percent increase in performance 
over sequential consistency. 5 The dis¬ 
advantage of the model is that the pro¬ 
grammer or compiler must identify all 
synchronization accesses. 

The Dash prototype supports the re¬ 
lease consistency model in hardware. 
Since we use commercial microproces¬ 
sors, the processor stalls on read opera¬ 
tions until the read data is returned 
from the cache or lower levels of the 
memory hierarchy. Write operations, 
however, are nonblocking. There is a 
write buffer between the first- and sec¬ 
ond-level caches. The write buffer 
queues up the write requests and issues 
them in order. Furthermore, the servic¬ 
ing of write requests is overlapped. As 
soon as the cache receives the owner¬ 
ship and data for the requested cache 
line, the write data is removed from the 
write buffer and written into the cache 
line. The next write request can be ser¬ 
viced while the invalidation acknowl¬ 
edgments for the previous write opera¬ 
tions filter in. Thus, parallelism exists at 
two levels: the processor executes other 
instructions and accesses its first-level 
cache while write operations are pend¬ 
ing, and invalidations of multiple write 
operations are overlapped. 

The Dash prototype also provides 
fence operations that stall the processor 
or write-buffer until previous opera¬ 
tions complete. These fence operations 
allow software to emulate more strin¬ 
gent consistency models. 

Memory access optimizations. The use 

of release consistency helps hide the 
latency of write operations. However, 


since the processor stalls on read oper¬ 
ations, it sees the entire duration of all 
read accesses. For applications that ex¬ 
hibit poor cache behavior or extensive 
read/write sharing, this can lead to sig¬ 
nificant delays while the processor waits 
for remote cache misses to be filled. To 
help with these problems Dash provides 
a variety of prefetch and pipelining op¬ 
erations. 

Prefetch operations. A prefetch oper¬ 
ation is an explicit nonblocking request 
to fetch data before the actual memory 
operation is issued. Hopefully, by the 
time the process needs the data, its val¬ 
ue has been brought closer to the pro¬ 
cessor, hiding the latency of the regular 
blocking read. In addition, nonblocking 
prefetch allows the pipelining of read 
misses when multiple cache blocks are 
prefetched. As a simple example of its 
use, a process wanting to access a row of 
a matrix stored in another cluster’s mem¬ 
ory can do so efficiently by first issuing 
prefetch reads for all cache blocks cor¬ 
responding to that row. 

Dash’s prefetch operations are non¬ 
binding and software controlled. The 
processor issues explicit prefetch oper¬ 
ations that bring a shared or exclusive 
copy of the memory block into the pro¬ 
cessor’s cache. Not binding the value at 
the time of the prefetch is important in 
that issuing the prefetch does not affect 
the consistency model or force the com¬ 
piler to do a conservative static depen¬ 
dency analysis. The coherence protocol 
keeps the prefetched cache line coher¬ 
ent. If another processor happens to 
write to the location before the prefetch¬ 
ing processor accesses the data, the data 
will simply be invalidated. The prefetch 
will be rendered ineffective, but the pro¬ 
gram will execute correctly. Support for 
an exclusive prefetch operation aids 
cases where the block is first read and 
then updated. By first issuing the exclu¬ 
sive prefetch, the processor avoids first 
obtaining a shared copy and then hav¬ 
ing to rerequest an exclusive copy of the 
block. Studies have shown that, for cer¬ 
tain applications, the addition of a small 
number of prefetch instructions can in¬ 
crease processor utilization by more than 
a factor of two. 6 

Update and deliver operations. In some 
applications, it may not be possible for 
the consumer process to issue a prefetch 
early enough to effectively hide the la¬ 
tency of memory. Likewise, if multiple 
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consumers need the same item of data, 
the communication traffic can be re¬ 
duced if data is multicast to all the con¬ 
sumers simultaneously. Therefore, Dash 
provides operations that allow the pro¬ 
ducer to send data directly to consum¬ 
ers. There are two ways for the produc¬ 
ing processor to specify the consuming 
processors. The update-write operation 
sends the new data directly to all proces¬ 
sors that have cached the data, while the 
deliver operation sends the data to spec¬ 
ified clusters. 

The update-write primitive updates the 
value of all existing copies of a data 
word. Using this primitive, a processor 
does not need to first acquire an exclu¬ 
sive copy of the cache line, which would 
result in invalidating all other copies. 
Rather, data is directly written into the 
home memory and all other caches hold¬ 
ing a copy of the line. These semantics 
are particularly useful for event synchro¬ 
nization, such as the release event for a 
barrier. 

The deliver instruction explicitly spec¬ 
ifies the destination clusters of the trans¬ 
fer. To use this primitive, the producer 
first writes into its cache using normal, 
invalidating write operations. The pro¬ 
ducer then issues a deliver instruction, 
giving the destination clusters as a bit 
vector. A copy of the cache line is then 
sent to the specified clusters, and the 
directory is updated to indicate that the 
various clusters now share the data. This 
operation is useful in cases when the 
producer makes multiple writes to a block 
before the consumers will want it or 
when the consumers are unlikely to be 
caching the item at the time of the write. 

Support for synchronization. The ac¬ 
cess patterns to locations used for syn¬ 
chronization are often different from 
those for other shared data. For exam¬ 
ple, whenever a highly contended lock is 
released, waiting nodes rush to grab the 
lock. In the case of barriers, many pro¬ 
cessors must be synchronized and then 
released. Such activity often causes hot 
spots in the memory system. Consequent¬ 
ly, synchronization variables often war¬ 
rant special treatment. In addition to 
update writes, Dash provides two exten¬ 
sions to the coherence protocol that di¬ 
rectly support synchronization objects. 
The first is queue-based locks, and the 
second is fetch-and-increment opera¬ 
tions. 

Most cache-coherent architectures 
handle locks by providing an atomic 


test&set instruction and a cached test- 
and-test&set scheme for spin waiting. 
Ideally, these spin locks should meet 
the following criteria: 

• minimum amount of traffic gener¬ 
ated while waiting, 

• low latency release of a waiting pro¬ 
cessor, and 

• low latency acquisition of a free lock. 

Cached test&set schemes are moder¬ 
ately successful in satisfying these crite¬ 
ria for low-contention locks, but fail for 
high-contention locks. For example, 
assume there are ^processors spinning 
on a lock value in their caches. When 
the lock is released, all N cache values 
are invalidated, and N reads are gener¬ 
ated to the memory system. Depending 
on the timing, it is possible that all N 
processors come back to do the test&set 
on the location once they realize the 
lock is free, resulting in further invali¬ 
dations and rereads. Such a scenario 
produces unnecessary traffic and increas¬ 
es the latency in acquiring and releasing 
a lock. 

The queue-based locks in Dash ad¬ 
dress this problem by using the directo¬ 
ry to indicate which processors are spin¬ 
ning on the lock. When the lock is 
released, one of the waiting clusters is 
chosen at random and is granted the 
lock. The grant request invalidates only 
that cluster’s caches and allows one pro¬ 
cessor within that cluster to acquire the 
lock with a local operation. This scheme 
lowers both the traffic and the latency 
involved in releasing a processor wait¬ 
ing on a lock. Informing only one clus¬ 
ter of the release also eliminates unnec¬ 
essary traffic and latency that would be 
incurred if all waiting processors were 
allowed to contend. A time-out mecha¬ 
nism on the lock grant allows the grant 
to be sent to another cluster if the spin¬ 
ning process has been swapped out or 
migrated. The queued-on-lock-bit 
primitive described in Goodman et al. 7 
is similar to Dash’s queue-based locks, 
but uses pointers in the processor cach¬ 
es to maintain the list of the waiting 
processors. 

The fetch-and-increment and fetch- 
and-decrement primitives provide atomic 
increment and decrement operations on 
uncached memory locations. The value 
returned by the operations is the value 
before the increment or decrement. 
These operations have low serialization 
and are useful for implementing several 


synchronization primitives such as bar¬ 
riers, distributed loops, and work queues. 
The serialization of these operations is 
small because they are done directly at 
the memory site. The low serialization 
provided by the fetch-and-increment 
operation is especially important when 
many processors want to increment a 
location, as happens when getting the 
next index in a distributed loop. The 
benefits of the proposed operations 
become apparent when contrasted with 
the alternative of using a normal vari¬ 
able protected by a lock to achieve the 
atomic increment and decrement. The 
alternative results in significantly more 
traffic, longer latency, and increased 
serialization. 

The Dash 
implementation 

A hardware prototype of the Dash 
architecture is currently under construc¬ 
tion. While we have developed a de¬ 
tailed software simulator of the system, 
we feel that a hardware implementation 
is needed to fully understand the issues 
in the design of scalable cache-coherent 
machines, to verify the feasibility of 
such designs, and to provide a platform 
for studying real applications and soft¬ 
ware running on a large ensemble of 
processors. 

To focus our effort on the novel as¬ 
pects of the design and to speed the 
completion of a usable system, the base 
cluster hardware used in the prototype 
is a commercially available bus-based 
multiprocessor. While there are some 
constraints imposed by the given hard¬ 
ware, the prototype satisfies our prima¬ 
ry goals of scalable memory bandwidth 
and high performance. The prototype 
includes most of Dash’s architectural 
features since many of them can only be 
fully evaluated on the actual hardware. 
The system also includes dedicated per¬ 
formance monitoring logic to aid in the 
evaluation. 

Dash prototype cluster. The proto¬ 
type system uses a Silicon Graphics 
Power Station 4D/340 as the base clus¬ 
ter. The 4D/340 system consists of four 
Mips R3000 processors and R3010 float¬ 
ing-point coprocessors running at 33 
megahertz. Each R3000/R3010 combi¬ 
nation can reach execution rates up to 
25 VAX MIPS and 10 Mflops. Each 
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CPU contains a 64-kilobyte instruction 
cache and a 64-Kbyte write-through data 
cache. The 64-Kbyte data cache inter¬ 
faces to a 256-Kbyte second-level write¬ 
back cache. The interface consists of a 
read buffer and a four-word-deep write 
buffer. Both the first- and second-level 
caches are direct-mapped and support 
16-byte lines. The first level caches run 
synchronously to their associated 33- 
MHz processors while the second level 
caches run synchronous to the 16-MHz 
memory bus. 

The second-level processor caches are 
responsible for bus snooping and main¬ 
taining coherence among the caches in 
the cluster. Coherence is maintained 
using an Illinois, or MESI (modified, 
exclusive, shared, invalid), protocol. The 
main advantage of using the Illinois pro¬ 
tocol in Dash is the cache-to-cache trans¬ 
fers specified in it. While they do little 


to reduce the latency for misses ser¬ 
viced by local memory, local cache-to- 
cache transfers can greatly reduce the 
penalty for remote memory misses. The 
set of processor caches acts as a cluster 
cache for remote memory. The memory 
bus (MPbus) of the 4D/340 is a synchro¬ 
nous bus and consists of separate 32-bit 
address and 64-bit data buses. The MP¬ 
bus is pipelined and supports memory- 
to-cache and cache-to-cache transfers 
of 16 bytes every four bus clocks with a 
latency of six bus clocks. This results in 
a maximum bandwidth of 64 Mbytes 
per second. While the MPbus is pipe¬ 
lined, it is not a split-transaction bus. 

To use the 4D/340 in Dash, we have 
had to make minor modifications to the 
existing system boards and design a pair 
of new boards to support the directory 
memory and intercluster interface. The 
main modification to the existing boards 


is to add a bus retry signal that is used 
when a request requires service from a 
remote cluster. The central bus arbiter 
has also been modified to accept a mask 
from the directory. The mask holds off 
a processor’s retry until the remote re¬ 
quest has been serviced. This effective¬ 
ly creates a split-transaction bus proto¬ 
col for requests requiring remote service. 
The new directory controller boards 
contain the directory memory, the in¬ 
tercluster coherence state machines and 
buffers, and a local section of the global 
interconnection network. The intercon¬ 
nection network consists of a pair of 
wormhole routed meshes, each with 16- 
bit wide channels. One mesh is dedicat¬ 
ed to the request messages while the 
other handles replies. Figure 4 shows a 
block diagram of four clusters connect¬ 
ed to form a 2 x 2 Dash system. Such a 
system could scale to support hundreds 
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Figure 6. Flow of a read request to remote memory that is dirty in a remote 
cluster. 


of processors, but the prototype will be 
limited to a maximum configuration of 
16 clusters. This limit was dictated pri¬ 
marily by the physical memory addres¬ 
sability (256 Mbytes) of the 4D/340 sys¬ 
tem, but still allows for systems up to 64 
processors that are capable of 1.6 GIPS 
and 600 scalar Mflops. 

Dash directory logic. The directory 
logic implements the directory-based 
coherence protocol and connects the 
clusters within the system. Figure 5 shows 
a block diagram of the directory boards. 
The directory logic is split between the 
two logic boards along the lines of the 
logic used for outbound and inbound 
portions of intercluster transactions. 

The directory controller (DC) board 
contains three major sections. The first 
is the directory controller itself, which 
includes the directory memory associ¬ 
ated with the cachable main memory 
contained within the cluster. The DC 
logic initiates all outbound network re¬ 
quests and replies. The second section 
is the performance monitor, which can 
count and trace a variety of intra- and 
intercluster events. The third major sec¬ 
tion is the request and reply outbound 
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network logic together with the ^-di¬ 
mension of the network itself. 

Each bus transaction accesses direc¬ 
tory memory. The directory informa¬ 
tion is combined with the type of bus 
operation, the address, and the result of 
snooping on the caches to determine 
what network messages and bus con¬ 
trols the DC will generate. The directo¬ 
ry memory itself is implemented as a bit 
vector with one bit for each of the 16 
clusters. While a full-bit vector has lim¬ 
ited scalability, it was chosen because it 
requires roughly the same amount of 
memory as a limited pointer directory 
given the size of the prototype, and it 
allows for more direct measurements of 
the machine’s caching behavior. Each 
directory entry contains a single state 
bit that indicates whether the clusters 
have a shared or dirty copy of the data. 
The directory is implemented using dy¬ 
namic RAM technology, but performs 
all necessary actions within a single bus 
transaction. 

The second board is the reply con¬ 
troller (RC) board, which also contains 
three major sections. The first section is 
the reply controller, which tracks out¬ 
standing requests made by the local pro¬ 
cessors and receives and buffers replies 
from remote clusters using the remote 
access cache (RAC). The second sec¬ 
tion is the pseudo-CPU (PCPU), which 
buffers incoming requests and issues 
them to the cluster bus. The PCPU mim¬ 
ics a CPU on this bus on behalf of re¬ 
mote processors except that responses 
from the bus are sent out by the directo¬ 
ry controller. The final section is the 
inbound network logic and the y-di- 
mension of the mesh routing networks. 

The reply controller stores the state 
of ongoing requests in the remote ac¬ 
cess cache. The RAC’s primary role is 
the coordination of replies to interclus¬ 
ter transactions. This ranges from the 
simple buffering of reply data between 
the network and bus to the accumula¬ 
tion of invalidation acknowledgments 
and the enforcement of release consis¬ 
tency. The RAC is organized as a 128- 
Kbyte direct-mapped snoopy cache with 
16-byte cache lines. 

One port of the RAC services the 
inbound reply network while the other 
snoops on bus transactions. The RAC is 
lockup-free in that it can handle several 
outstanding remote requests from each 
of the local processors. RAC entries are 
allocated when a local processor ini¬ 
tiates a remote request, and they persist 


until all intercluster transactions rela¬ 
tive to that request have completed. 
The snoopy nature of the RAC natural¬ 
ly lends itself to merging requests made 
to the same cache block by different 
processors and takes advantage of the 
cache-to-cache transfer protocol sup¬ 
ported between the local processors. 
The snoopy structure also allows the 
RAC to supplement the function of the 
processor caches. This includes support 
for a dirty-sharing state for a cluster 
(normally the Illinois protocol would 
force a write-back) and operations such 
as prefetch. 

Interconnection network. As stated 
in the architecture section, the Dash 
coherence protocol does not rely on a 
particular interconnection network to¬ 
pology. However, for the architecture 
to be scalable, the network itself must 
provide scalable bandwidth. It should 
also provide low-latency communica¬ 
tion. The prototype system uses a pair 
of wormhole routed meshes to imple¬ 
ment the interconnection network. One 
mesh handles request messages while 
the other is dedicated to replies. The 
networks are based on variants of the 
mesh routing chips developed at the 
California Institute of Technology, 
where the data paths have been extend¬ 
ed from 8 to 16 bits. Wormhole routing 
allows a cluster to forward a message 
after receiving only the first flit (flow 
unit) of the packet, greatly reducing the 
latency through each node. The aver¬ 
age latency for each hop in the network 
is approximately 50 nanoseconds. The 
networks are asynchronous and self- 
timed. The bandwidth of each link is 
limited by the round-trip delay of the 
request-acknowledge signals. The pro¬ 
totype transfers flits at approximately 
30 MHz, resulting in a total bandwidth 
of 120 Mbytes/second in and out of each 
cluster. 

An important constraint on the net¬ 
work is that it must deliver request and 
reply messages without deadlocking. 
Most networks, including the meshes 
used in Dash, are guaranteed to be dead¬ 
lock-free if messages are consumed at 
the receiving cluster. Unfortunately, the 
Dash prototype cannot guarantee this 
due, first, to the limited buffering on the 
directory boards and also to the fact 
that a cluster may need to generate an 
outgoing message before it can con¬ 
sume an incoming message. For exam¬ 
ple, to service a read request, the home 


cluster must generate a reply message 
containing the data. Similarly, to pro¬ 
cess a request for a dirty location in a 
remote cluster, the home cluster needs 
to generate a forwarding request to that 
cluster. This requirement adds the po¬ 
tential for deadlocks that consist of a 
sequence of messages having circular 
dependencies through a node. 

Dash avoids these deadlocks through 
three mechanisms. First, reply messag¬ 
es can always be consumed because they 
are allocated a dedicated reply buffer in 
the RAC. Second, the independent re¬ 
quest and reply meshes eliminate re¬ 
quest-reply deadlocks. Finally, a back¬ 
off mechanism breaks potential 
deadlocks due to request-request de¬ 
pendencies. If inbound requests cannot 
be forwarded because of blockages on 
the outbound request port, the requests 
are rejected by sending negative ac¬ 
knowledgment reply messages. Reject¬ 
ed requests are then retried by the issu¬ 
ing processor. 

Coherence examples. The following 
examples illustrate how the various struc¬ 
tures described in the previous sections 
interact to carry out the coherence pro¬ 
tocol. For a more detailed discussion of 
the protocol, see Lenoski et al. 8 

Figure 6 shows a simple read of a 
memory location whose home is in a 
remote cluster and whose directory state 
is dirty in another cluster. The read 
request is not satisfied on the local clus¬ 
ter bus, so a Read-Req (message 1) is 
sent to the home. At this time the pro¬ 
cessor is told to retry, and its arbitration 
is masked. A RAC entry is allocated to 
track this message and assign owner¬ 
ship of the reply. The PCPU at the home 
receives the Read-Req and issues a cache 
read on the bus. The directory memory 
is accessed and indicates that the cache 
block is dirty in another cluster. The 
directory controller in the home for¬ 
wards the Read-Req (message 2) to the 
dirty remote cluster. The PCPU in the 
dirty cluster issues the read on the dirty 
cluster’s bus and the dirty processor’s 
cache responds. The DC in the dirty 
cluster sends a Read-Rply (message 3a) 
to the local cluster and a Sharing-Write- 
back (message 3b) request to the home 
to update the directory and main mem¬ 
ory. The RC in the local cluster receives 
the reply into the RAC, releases the 
requesting CPU for arbitration, and then 
sources the data onto the bus when the 
processor retries the read. In parallel, 
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Local cluster 



Figure 7. Flow of a read-exclusive request to remote memory that is shared in 
remote clusters. 


the Sharing-Writeback request is re¬ 
ceived by the home PCPU, which issues 
it onto the bus. The sharing writeback 
updates the directory to a shared state 
indicating that the local and dirty clus¬ 
ters now have a read-only copy of the 
memory block. 

Figure 7 shows the corresponding se¬ 
quence for a store operation that re¬ 
quires remote service. The invalidation- 
based protocol requires the processor 
(actually the write buffer) to acquire 
exclusive ownership of the cache block 
before completing the store. Thus, if a 
store is made to a block that the proces¬ 
sor does not have cached, or only has 
cached in a shared state, the processor 
issues a read-exclusive request on the 
local bus. In this case, no other cache 
holds the block dirty in the local cluster 
so a Read-Ex Req (message 1) is sent to 
the home cluster. As before, a RAC 
entry is allocated in the local cluster. At 
the home, the PCPU issues the read- 
exclusive request to the bus. The direc¬ 
tory indicates that the line is in the 
shared state. This results in the DC send¬ 
ing a Read-Ex Rply (message 2a) to the 
local cluster and invalidation requests 
(Inv-Req, messages 2b) to the sharing 
clusters. The home cluster owns the 
block, so it can immediately update the 
directory to the dirty state indicating 
that the local cluster now holds an ex¬ 
clusive copy of the memory line. The 
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Read-Ex Rply message is received in 
the local cluster by the RC, which can 
then satisfy the read-exclusive request. 
To assure consistency at release points, 
however, the RAC entry persists even 
after the write-buffer’s request is satis¬ 
fied. The RAC entry is only deallocated 
when it receives the number of invali¬ 
date acknowledgments (Inv-Ack, mes¬ 
sage 3) equal to an invalidation count 
sent in the original reply message. The 
RC maintains per-processor RAC allo¬ 
cation counters to allow the hardware 
to stall releasing synchronization oper¬ 
ations until all earlier writes issued by 
the given processor have completed sys¬ 
temwide. 

An important feature of the coher¬ 
ence protocol is its forwarding strategy. 
If a cluster cannot reply directly to a 
given request, it forwards responsibility 
for the request to a cluster that should 
be able to respond. This technique min¬ 
imizes the latency for a request, as it 
always forwards the request to where 
the data is thought to be and allows a 
reply to be sent directly to the request¬ 
ing cluster. This technique also mini¬ 
mizes the serialization of requests since 
no cluster resources are blocked while 
intercluster messages are being sent. 
Forwarding allows the directory con¬ 
troller to work on multiple requests con¬ 
currently (that is, makes it multithread¬ 
ed) without having to retain any 
additional state about forwarded re¬ 
quests. 

Software support 

A comprehensive software develop¬ 
ment environment is essential to make 
effective use of large-scale multiproces¬ 
sors. For Dash, our efforts have focused 
on four major areas: operating systems, 
compilers, programming languages, and 
performance debugging tools. 

Dash supports a full-function Unix 
operating system. In contrast, many oth¬ 
er highly parallel machines (for exam¬ 
ple, Intel iPSC2, Ncube, iWarp) sup¬ 
port only a primitive kernel on the node 
processors and rely on a separate host 
system for program development. Dash 
avoids the complications and inefficien¬ 
cies of a host system. Furthermore, the 
resident operating system can efficient¬ 
ly support multiprogramming and mul¬ 
tiple users on the system. Developed in 
cooperation with Silicon Graphics, the 
Dash OS is a modified version of the 


existing operating system on the 4D/ 
340 (Irix, a variation of Unix System 
V.3). Since Irix was already multithread¬ 
ed and worked with multiple proces¬ 
sors, many of our changes have been 
made to accommodate the hierarchical 
nature of Dash, where processors, main 
memory, and I/O devices are all parti¬ 
tioned across the clusters. We have also 
adapted the Irix kernel to provide ac¬ 
cess to the special hardware features of 
Dash such as prefetch, update write, 
and queue-based locks. Currently, the 
modified OS is running on a four- 
cluster Dash system, and we are explor¬ 
ing several new algorithms for process 
scheduling and memory allocation that 
will exploit the Dash memory hierar¬ 
chy. 

At the user level, we are working on 
several tools to aid the development of 
parallel programs for Dash. At the most 
primitive level, a parallel macro library 
provides structured access to the under¬ 
lying hardware and operating-system 
functions. This library permits the de¬ 
velopment and porting of parallel ap¬ 
plications to Dash using standard lan¬ 
guages and tools. We are also developing 
a parallelizing compiler that extracts 
parallelism from programs written for 
sequential machines and tries to im¬ 
prove data locality. Locality is enhanced 
by increasing cache utilization through 
blocking and by reducing remote ac¬ 
cesses through static partitioning of com¬ 
putation and data. Finally, prefetching 
is used to hide latency for remote ac¬ 
cesses that are unavoidable. 

Because we are interested in using 
Dash for a wide variety of applications, 
we must also find parallelism beyond 
the loop level. To attack this problem 
we have developed a new parallel lan¬ 
guage called Jade, which allows a pro¬ 
grammer to easily express dynamic 
coarse-grain parallelism. Starting with 
a sequential program, a programmer 
simply augments those sections of code 
to be parallelized with side-effect infor¬ 
mation. The compiler and runtime sys¬ 
tem use this information to execute the 
program concurrently while respecting 
the program’s data dependence con¬ 
straints. Using Jade can significantly 
reduce the time and effort required to 
develop a parallel version of a serial 
application. A prototype of Jade is op¬ 
erational, and applications developed 
with Jade include sparse-matrix 
Cholesky factorization, Locus Route (a 
printed-circuit-board routing algo¬ 


rithm), and MDG (a water simulation 
code). 

To complement our compiler and lan¬ 
guage efforts, we are developing a suite 
of performance monitoring and analy¬ 
sis tools. Our high-level tools can iden¬ 
tify portions of code where the concur¬ 
rency is smallest or where the most 
execution time is spent. The high-level 
tools also provide information about 
synchronization bottlenecks and load¬ 
balancing problems. Our low-level tools 
will couple with the built-in hardware 
monitors in Dash. As an example, they 
will be able to identify portions of code 
where most cache misses are occurring 
and will frequently provide the reasons 
for such misses. We expect such nonin- 
vasive monitoring and profiling tools to 
be invaluable in pinpointing critical 
regions for optimization to the program¬ 
mer. 

Dash performance 

This section presents performance 
data from the Dash prototype system. 
First, we summarize the latency for 
memory accesses serviced by the three 
lower levels of the memory hierarchy. 
Second, we present speedup for three 
parallel applications running on a simu¬ 
lation of the prototype using one to 64 
processors. Finally, we present the ac¬ 
tual speedups for these applications 
measured on the initial 16-processor 
Dash system. 

While caches reduce the effective ac¬ 
cess time of memory, the latency of 
main memory determines the sensitivi¬ 
ty of processor utilization to cache and 
cluster locality and indicates the costs 
of interprocessor communication. Fig¬ 
ure 8 shows the unloaded latencies for 
read misses that are satisfied within the 
local cluster, within the home cluster, 
and by a remote (that is, dirty) cluster. 
Latencies for read-exclusive requests 
issued by the write buffer are similar. A 
read miss to the local cluster takes 29 
processor clocks (870 ns), while a re¬ 
mote miss takes roughly 3.5 times as 
long. The delays arise primarily from 
the relatively slow bus in the 3D/340 
and from our implementation’s conser¬ 
vative technology and packaging. De¬ 
tailed simulation has shown that queu¬ 
ing delays can add 20 to 120 percent to 
these delays. While higher levels of in¬ 
tegration could reduce the absolute time 
of the prototype latencies, we believe 
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Figure 9. Speedup of three parallel applications on a simulation of the Dash prototype with one to 64 processors: (a) 
overall application speedup; (b) marginal efficiency of additional clusters. 



Figure 10. Speedup of three parallel applications on the actual Dash prototype hardware with one to 16 processors: (a) 
overall application speedup; (b) marginal efficiency of additional clusters. 


the increasing clock rate of micropro¬ 
cessors implies that the latencies mea¬ 
sured in processor clocks will remain 
similar. 

Applications for large-scale multipro¬ 
cessors must utilize locality to realize 
good cache hit rates, minimize remote 
accesses, and achieve high processor 
utilization. Figure 9 shows the speedup 
and processor efficiency for three appli¬ 


cations on simulated Dash systems con¬ 
sisting of one to 64 processors (that is, 
one to 16 clusters). The line graph shows 
overall application speedup, while the 
bar chart shows the marginal efficiency 
of additional clusters. The marginal ef¬ 
ficiency is defined as the average pro¬ 
cessor utilization, assuming processors 
were 100 percent utilized at the previ¬ 
ous data point. The three applications 


simulated are Water, Mincut, and MP3D. 
Water is a molecular-dynamics code that 
computes the energy of a system of wa¬ 
ter molecules. Mincut uses parallel sim¬ 
ulated annealing to solve a graph-parti¬ 
tioning problem. MP3D models a wind 
tunnel in the upper atmosphere, using a 
discrete particle-based simulation. 

The applications were simulated us¬ 
ing a combination of the Tango multi- 


76 


COMPUTER 






















































































processor simulator and a detailed mem¬ 
ory simulator for the Dash prototype. 
Tango allows a parallel application to 
run on a uniprocessor and generates a 
parallel memory-reference stream. The 
detailed memory simulator is tightly 
coupled with Tango and provides feed¬ 
back on the latency of individual mem¬ 
ory operations. 

On the Dash simulator, Water and 
Mincut achieve reasonable speedup 
through 64 processors. For Water, the 
reason is that the application exhibits 
good locality. As the number of clusters 
increases from two to 16, cache hit rates 
are relatively constant, and the percent 
of cache misses handled by the local 
cluster only decreases from 69 to 64 
percent. Thus, miss penalties increase 
only slightly with system size and do not 
adversely affect processor utilizations. 
For Mincut, good speedup results from 
very good cache hit rates (98 percent for 
shared references). The speedup falls 
off for 64 processors due to lock conten¬ 
tion in the application. 

MP3D obviously does not exhibit good 
speedup on the Dash prototype. This 
particular encoding of the MP3D appli¬ 
cation requires frequent interprocessor 
communication, thus resulting in fre¬ 
quent cache misses. On average, about 
4 percent of the instructions executed in 
MP3D generate a read miss for a shared 
data item. When only one cluster is 
being used, all these misses are serviced 
locally. However, when we go to two 
clusters, a large fraction of the cache 
misses are serviced remotely. This more 
than doubles the average miss latency, 
thus nullifying the potential gain from 
the added processors. Likewise, when 
four clusters are used, the full benefit is 
not realized because most misses are 
now serviced by a remote dirty cache, 
requiring a three-hop access. 

Reasonable speedup is finally 
achieved when going from 16 to 32 and 
64 processors (77 percent and 86 per¬ 
cent marginal efficiency, respectively), 
but overall speedup is limited to 14.2. 
Even on MP3D, however, caching is 
beneficial. A 64-processor system with 
the timing of Dash, but without the 
caching of shared data, achieves only a 
4.1 speedup over the cached uniproces¬ 
sor. For Water and Mincut the improve¬ 
ments from caching are even larger. 

Figure 10 shows the speedup for the 
three applications on the real Dash hard¬ 
ware using one to 16 processors. The 
applications were run under an early 


version of the Dash OS. The results for 
Water and Mincut correlate well with 
the simulation results, but the MP3D 
speedups are somewhat lower. The prob¬ 
lem with MP3D appears to be that sim¬ 
ulation results did not include private 
data references. Since MP3D puts a 
heavy load on the memory system, the 
extra load of private misses adds to the 
queuing delays and reduces the multi¬ 
processor speedups. 

We have run several other applica¬ 
tions on our 16-processor prototype. 
These include two hierarchical n-body 
applications (using Barnes-Hut and 
Greengard-Rokhlin algorithms), a ra- 
diosity application from computer graph¬ 
ics, a standard-cell routing application 
from very large scale integration com¬ 
puter-aided design, and several matrix- 
oriented applications, including one 
performing sparse Cholesky factoriza¬ 
tion. There is also an improved version 
of the MP3D application that exhibits 
better locality and achieves almost lin¬ 
ear speedup on the prototype. 

Over this initial set of 10 parallel ap¬ 
plications, the harmonic mean of the 
speedup on 16 processors in 10.5 Fur¬ 
thermore, if old MP3D is left out, the 
harmonic mean rises to over 12.8. Over¬ 
all, our experience with the 16-proces- 
sor machine has been very promising 
and indicates that many applications 
should be able to achieve over 40 times 
speedup on the 64-processor system. 


Related work 

There are other proposed scalable 
architectures that support a single ad¬ 
dress space with coherent caches. A 
comprehensive comparison of these 
machines with Dash is not possible at 
this time, because of the limited experi¬ 
ence with this class of machines and the 
lack of details on many of the critical 
machine parameters. Nevertheless, a 
general comparison illustrates some of 
the design trade-offs that are possible. 

Encore GigaMax and Stanford Para¬ 
digm. The Encore GigaMax architec¬ 
ture 9 and the Stanford Paradigm project 10 
both use a hierarchy-of-buses approach 
to achieve scalability. At the top level, 
the Encore GigaMax is composed of 
several clusters on a global bus. Each 
cluster consists of several processor 
modules, main memory, and a cluster 
cache. The cluster cache holds a copy of 


all remote locations cached locally and 
also all local locations cached remote¬ 
ly. Each processing module consists of 
several processors with private caches 
and a large, shared, second-level cache. 
A hierarchical snoopy protocol keeps 
the processor and cluster caches co¬ 
herent. 

The Paradigm machine is similar to 
the GigaMax in its hierarchy of proces¬ 
sors, caches, and buses. It is different, 
however, in that the physical memory is 
all located at the global level, and it 
uses a hierarchical directory-based co¬ 
herence protocol. The clusters contain¬ 
ing cached data are identified by a bit- 
vector directory at every level, instead 
of using snooping cluster caches. Para¬ 
digm also provides a lock bit per mem¬ 
ory block that enhances performance 
for synchronization and explicit com¬ 
munication. 

The hierarchical structure of these 
machines is appealing in that they can 
theoretically be extended indefinitely 
by increasing the depth of the hierar¬ 
chy. Unfortunately, the higher levels of 
the tree cannot grow indefinitely in 
bandwidth. If a single global bus is used, 
it becomes a critical link. If multiple 
buses are used at the top, the protocols 
become significantly more complex. Un¬ 
less an application’s communication re¬ 
quirements match the bus hierarchy or 
its traffic-sharing requirements are 
small, the global bus will be a bottle¬ 
neck. Both requirements are restrictive 
and limit the classes of applications that 
can be efficiently run on these machines. 

IEEE Scalable Coherent Interface. 

The IEEE P1596 Scalable Coherent In¬ 
terface (SCI) is an interface standard 
that also strives to provide a scalable 
system model based on distributed di¬ 
rectory-based cache coherence. 11 It dif¬ 
fers from Dash in that it is an interface 
standard, not a complete system de¬ 
sign. SCI only specifies the interfaces 
that each processing node should im¬ 
plement, leaving open the actual node 
design and exact interconnection net¬ 
work. SCI’s role as an interface stan¬ 
dard gives it somewhat different goals 
from those of Dash, but systems based 
on SCI are likely to have a system orga¬ 
nization similar to Dash. 

The major difference between SCI 
and Dash lies in how and where the 
directory information is maintained. In 
SCI, the directory is a distributed sharing 
list maintained by the processor caches 
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themselves. For example, if processors 
A, B, and C are caching some location, 
then the cache entries storing this loca¬ 
tion include pointers that form a doubly 
linked list. At main memory, only a 
pointer to the processor at the head of 
the linked list is maintained. In con¬ 
trast, Dash places all the directory in¬ 
formation with main memory. 

The main advantage of the SCI scheme 
is that the amount of directory pointer 
storage grows naturally as new process¬ 
ing nodes are added to the system. Dash- 
type systems generally require more di¬ 
rectory memory than SCI systems and 
must use a limited directory scheme to 
scale to a large configuration. On the 
other hand, SCI directories would typi¬ 
cally use the same static RAM technol¬ 
ogy as the processor caches while the 
Dash directories are implemented in 
main memory DRAM technology. This 
difference tends to offset the potential 
storage efficiency gains of the SCI 
scheme. 

The primary disadvantage of the SCI 
scheme is that the distribution of indi¬ 
vidual directory entries increases the 
latency and complexity of the memory 
references, since additional directory- 
update messages must be sent between 
processor caches. For example, on a 
write to a shared block cached by N 
processors (including the writing pro¬ 
cessor), the writer must perform the 
following actions: 

• detach itself from the sharing list, 
•interrogate memory to determine 

the head of the sharing list, 

•acquire head status from the cur¬ 
rent head, and 

• serially purge the other processor 
caches by issuing invalidation re¬ 
quests and receiving replies that in¬ 
dicate the next processor in the list. 

Altogether, this amounts to 2N + 6 
messages and, more importantly, N +1 
serial directory lookups. In contrast, 
Dash can locate all sharing processors 
in a single directory lookup, and invali¬ 
dation messages are serialized only by 
the network transmission rate. 

The SCI working committee has pro¬ 
posed several extensions to the base 
protocol to reduce latency and support 
additional functions. In particular, the 
committee has proposed the addition of 
directory pointers that allow sharing 
lists to become sharing trees, support 
for request forwarding, use of a clean 
cached state, and support for queue- 


based locks. While these extensions re¬ 
duce the differences between the two 
protocols, they also significantly increase 
the complexity of SCI. 

MIT Alewife. The Alewife machine 12 
is similar to Dash in that it uses main 
memory directories and connects the pro¬ 
cessing nodes with mesh network. There 
are three main differences between the 
two machines: 

• Alewife does not have a notion of 
clusters — each node is a single proces¬ 
sor. 

• Alewife uses software to handle di¬ 
rectory pointer overflow. 

• Alewife uses multicontext processors 
as its primary latency-hiding mechanism. 

The size of clusters (one processor, 
four processors, or more) is dictated pri¬ 
marily by the engineering trade-offs be¬ 
tween the overhead of hardware for each 
node (memory, network interface, and 
directory) and the bandwidth available 
within and between clusters. Techniques 
for scaling directories efficiently are a 
more critical issue. Whether hardware 
techniques, such as proposed in O’Krafka 
and Newton 2 and Gupta et al., 1 or the 
software techniques of Alewife will be 
more effective remains an open ques¬ 
tion, though we expect the practical dif¬ 
ferences to be small. Multiple contexts 
constitute a mechanism that helps hide 
memory latency, but one that clearly 
requires additional application parallel¬ 
ism to be effective. Overall, 
while we believe that support for multi¬ 
ple contexts is useful and can comple¬ 
ment other techniques, we do not feel 
that its role will be larger than other 
latency-hiding mechanisms such as re¬ 
lease consistency and nonbinding 
prefetch. 13 


W e have described the design 
and implementation deci¬ 
sions for Dash, a multipro¬ 
cessor that combines the programmabil¬ 
ity of single-address-space machines with 
the scalability of message-passing ma¬ 
chines. The key means to this scalability 
are a directory-based cache-coherence 
protocol, distributed memories and di¬ 
rectories, and a scalable interconnection 
network. The design focuses on reducing 
memory latency to keep processor per¬ 
formance high, though it also provides 
latency-hiding techniques such as 
prefetch and release consistency to mit¬ 


igate the effects of unavoidable system 
delays. 

At the time of this writing, the 2 x 2 
Dash prototype is stable. It is accessible 
on the Internet and used daily for re¬ 
search into parallel applications, tools, 
operating systems, and directory-based 
architectures. As indicated in the per¬ 
formance section, results from this ini¬ 
tial configuration are very promising. 
Work on extending the 2x2 cluster 
system to the larger 4x4 (64-processor) 
system is ongoing. All major hardware 
components are on hand and being de¬ 
bugged. By the time this article is in 
print, we expect to have an initial ver¬ 
sion of the Unix kernel and parallel 
applications running on the larger 
machine. ■ 
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UPDATE 


English-only orientation limits opportunities in today’s high-tech world 

Bob Carlson, Staff Editor 


l In an increasingly competitive inter¬ 

national high-tech marketplace, re¬ 
searchers, scientists, and engineers can 
no longer be certain that all the infor¬ 
mation they need to remain in the fore¬ 
front of their fields will be available in 
English. In fact, some sources now 
claim that half of the world’s scientific 
information is being published in lan¬ 
guages other than English. 

Conceptually, the world continues 
to shrink, but language barriers re¬ 
mind us of the distances that still sep¬ 
arate us. Technology has made it easy 
to pick up a telephone or send an e- 
mail message and reach almost any 
part of the world, yet we cannot al¬ 
ways be sure that our efforts at com¬ 
munication will be effective. With ac¬ 
cess to foreign markets and suppliers 
becoming more vital, and researchers 
needing to collaborate with colleagues 
worldwide, poor communication is a 
greater handicap than ever before. 

In the United States, where fluency 
in foreign languages has traditionally 
| lagged behind that of other nations, 
such developments can be unsettling. 
To some extent the presence in the 
US work force of immigrants with 
both high-tech skills and multilingual 
abilities has helped ameliorate this sit¬ 
uation, but many technical people still 
feel at a disadvantage when they must 
seek out others to interpret critical in¬ 
formation for them. 

Academia responds. The Massachu¬ 
setts Institute of Technology has rec¬ 
ognized the problem and is offering a 
summer course in technical Japanese 
for computer scientists and electrical 
engineers. The principal goal of the 
course is to enable participants to 
read technical Japanese-language doc¬ 
uments in their area of expertise. 

Yoshihisa Kitagawa, assistant lin¬ 
guistics professor at the University of 
Rochester, reports that the electrical 
engineering and language depart¬ 
ments at his university have proposed 
| joining forces for a similar effort. In 


the current climate of tight finances, 
however, the administration has not 
been able to approve the program. In 
the meantime, staff members in the 
University of Rochester’s language 
departments, like their counterparts 
at other institutions, continue to re¬ 
ceive requests for assistance and often 
help out on an ad hoc basis. 

Where to get translations. To meet 
the growing need for translations of 
scientific literature, the National 
Translations Center at the Library of 
Congress is expanding its service. The 
center is seeking cooperation from 
50,000 significant research centers in 
the US, including government agen¬ 
cies and private industry, asking them 
to share American translating re¬ 
sources. The NTC guarantees ano¬ 
nymity for contributing organizations. 

Current unpublished English trans¬ 
lations of critical research from inter¬ 
national technical journals, patents, 
and conference papers are collected at 
the center, cataloged, and offered for 
$35 with 24-hour turnaround. 

Through an arrangement with the 
Copyright Clearance Center, the NTC 
is able to comply with US code con¬ 
cerning copying and distribution. 

Organizations contemplating con¬ 
tracting for the services of a translator 
would do well to check with the cen¬ 
ter first and perhaps avoid the time 
and expense of redundant translation 
effort. Inquiries can be directed to the 
National Translations Center, Library 
of Congress, Washington, DC 20541, 
phone (202) 707-0100, fax (202) 707- 
6147. 

Help with the spoken word. Even 
those who can read the scientific liter¬ 
ature in another language are often 
less confident when it comes to con¬ 
versation. In response to the growing 
number of international business calls, 
AT&T offers Language Line Inter¬ 
preter Services. By dialing (800) 628- 


8486, callers can arrange to have an 
interpreter come on the line and assist 
them. 

For many participants at interna¬ 
tional conferences, English is a second 
or third language, and fluency may be 
limited. If those whose native tongue 
is English would imagine themselves 
at a conference conducted in, say, 
German, French, or Japanese, they 
would quickly appreciate the difficul¬ 
ties many of their colleagues face. So 
it is always encouraging to find that in 
the search for better communication 
about technology, partial solutions are 
being offered by technology itself. 

Computer-aided translation. Work¬ 
ing in collaboration with Siemens, 
A.G., ATR (Kyoto, Japan), and the 
University of Karlsruhe in Germany, 
Carnegie Mellon’s Center for Ma¬ 
chine Translation developed a contin¬ 
uous-speech translation system that 
was demonstrated last summer in 
Germany, helping English and Ger¬ 
man speakers register for a confer¬ 
ence. Working with a 400-word vocab¬ 
ulary, the Janus system translates 
spoken English, German, and Japa¬ 
nese using neural networks to achieve 
accuracy even when the meaning and 
sounds of a sentence are not clear. 

Janus operates on a standard work¬ 
station, with response time ranging 
from 7 to 30 seconds. The modules 
run sequentially but could be pipe¬ 
lined, explained Alex Waibel, senior 
research scientist at Carnegie Mellon. 
In the present research environment, 
however, speed is less of a priority 
than the system’s ability to learn. 
Waibel believes that with more devel¬ 
opment, real-time performance on a 
PC is possible. 

Over the long term, Waibel sees 
commercial systems with larger vo¬ 
cabularies being developed for other 
domains. He invites us to imagine, for 
example, a company providing mail¬ 
order service to speakers of foreign 
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languages via an automated phone 
line. 

A number of text translation sys¬ 
tems are in use worldwide, though 
they are frequently developed by 


companies outside the US. This may 
be, as Waibel suggests, because speak¬ 
ers of German and Japanese felt 
somewhat isolated from the techno¬ 
logical mainstream and found comput¬ 


erized translation aids especially ben¬ 
eficial. If current trends continue, in¬ 
terest in machine translation, as well 
as the study of languages, may expand 
significantly in the US. 


Transaction processing benchmark submitted for public review 


The Transaction Processing Perfor¬ 
mance Council has made its newest 
industry-standard benchmark, TPC-C, 
available for public review in prepara¬ 
tion for final acceptance in June. 

TPC-C is modeled after an order- 
entry work load in ah on-line transac¬ 
tion processing environment. The 
benchmark contains a mixture of 
read-only and update-intensive trans¬ 


actions that simulate the complex ac¬ 
tivities present in a distributed busi¬ 
ness environment. 

TPC-C retains many of the features 
of TPC-A but is designed to cover as¬ 
pects of real-life systems not found in 
the simpler model. For example, TPC- 
C requires processing of five different 
types of transactions, while TPC-A re¬ 
quires processing of only one. In addi¬ 


tion, TPC-C requires a more complex 
database structure and higher levels 
of data and memory contention. 

Copies of TPC-C can be obtained 
by contacting the Transaction Pro¬ 
cessing Performance Council, do 
Shanley Public Relations, 111 N. First 
St., Suite 600, San Jose, CA 95112- 
6113, phone (408) 295-8894, fax (408) 
295-2613. 


Milner, Patterson receive major ACM awards 


Robin Milner of the University of 
Edinburgh, Scotland, is the winner of 
the 1991 A.M. Turing Award, and 
David A. Patterson of the University 
of California at Berkeley received the 
1991 Karl V. Karlstrom Outstanding 
Educator Award. Both presentations 
are to be made at the ACM Computer 
Science Conference in Kansas City, 
Missouri, March 3. 

Turing Award. Milner was cited for 
“establishing an international reputa¬ 
tion for three distinct and complete 
achievements, each of which has had 
and will continue to have a marked, 
important, and widespread effect on 
both the theory and practice of com¬ 
puter science.” 

His achievements over the past 20 
years, as cited by ACM’s Awards 
Committee, include 

(1) LCF, the mechanization of 
Scott’s logic of computable functions, 
probably the first theoretically based 
yet practical tool for machine-assisted 
proof construction. 

(2) ML, the first language to con¬ 
tain polymorphic type-inference to¬ 


gether with a type-safe exception-han¬ 
dling mechanism. The type-inference 
algorithm applied to a full language is 
a major theoretical advance. 

(3) CCS, a general theory of con¬ 
currency. 

Milner is professor of computer sci¬ 
ence at the University of Edinburgh, 
where his work led to the establish¬ 
ment of the Laboratory for Founda¬ 
tions of Computer Science in 1986. 
The laboratory is committed to foun¬ 
dational research but also opens the 
doors to business and industry to 
transfer laboratory prototypes and 
gain feedback. 

Milner is a fellow of the Royal Soci¬ 
ety and a distinguished fellow of the 
British Computer Society. 

Named for the British mathemati¬ 
cian, the A.M. Turing Award includes 
a $25,000 prize provided by AT&T. 

Karlstrom Award. Patterson was 
cited for his pioneering work on re¬ 
duced instruction-set computing and 
for his teaching, described as “a strik¬ 
ing demonstration of the importance 
of the interaction between teaching 


and research.” According to the ACM 
Awards Committee, “His technique of 
involving students in team projects to 
develop innovative computer designs 
has played a key role in the develop¬ 
ment of RISC. He led three genera¬ 
tions of RISC courses and seminars, 
involving students in each step of the 
design, fabrication, and testing of a 
micro computer-on-a-chip. The RISC 
project not only produced a profound 
impact on computer technology but 
also resulted in a whole generation of 
academicians who have joined aca¬ 
demic departments and have won 
awards for distinguished disserta¬ 
tions.” 

Patterson coauthored the text Com¬ 
puter Architecture: A Quantitative Ap¬ 
proach and has made videotapes of 
his lectures available at cost to other 
universities. He is a fellow of the 
IEEE, a corporate fellow of Thinking 
Machines Corp., and a member of the 
IEEE Computer Society. 

The annual Karl V. Karlstrom 
Award to an outstanding educator in 
computer science or engineering in¬ 
cludes a $5,000 prize provided by 
Prentice Hall Publishing. 


Applications invited for NRC research associateships 


The National Research Council’s 
Resident, Cooperative, and Postdoc¬ 
toral Research Associateship Pro¬ 
grams for research in the sciences and 
engineering provide opportunities for 
PhD scientists and engineers of un¬ 
usual promise and ability to perform 
research on problems largely of their 
own choosing yet compatible with the 
research interests of sponsoring labo¬ 


ratories. The 1992 programs will be 
conducted on behalf of 30 federal 
agencies or research institutions with 
115 participating research laboratories 
throughout the US. 

Approximately 300 new full-time 
associateships will be awarded on a 
competitive basis in 1992 for research 
in chemistry; earth and atmospheric 
sciences; engineering and applied sci¬ 


ences; biological, health, and behav¬ 
ioral sciences and biotechnology; 
mathematics; space and planetary sci¬ 
ences; and physics. Most of the pro¬ 
grams are open to both US and non- 
US nationals and to both recent PhD 
recipients and senior investigators. 

Awards are made for one or two 
years, renewable to a maximum of 
three years. Senior applicants who 
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Nominations sought for IEEE fellowship 


have held the doctorate at least five 
years may request a shorter period. 
Annual stipends for recent PhDs for 
the 1992 program year range from 
$27,750 to $42,000, depending on the 
sponsoring laboratory, and will be ap¬ 
propriately higher for senior associ- 

Financial support is provided for al¬ 
lowable relocation expenses and for 
limited professional travel during the 
term of the award. The host laborato¬ 
ry provides the associate with pro¬ 
grammatic assistance, including facili¬ 
ties, support services, necessary 
equipment, and travel necessary for 
conducting the approved research. 

Information, deadlines, and applica¬ 
tion materials can be obtained from 
Associateship Programs (GR430/D2), 
Office of Scientific and Engineering 
Personnel, National Research Coun¬ 
cil, 2101 Constitution Ave. NW, 
Washington, DC 20418, fax (202) 334- 
2759. 

Series on computing set 
for viewing on PBS 

The Machine that Changed the 
World, a five-part series on the history 
and impact of computers, will pre¬ 
miere April 6 on PBS (check local list¬ 
ings). Thomas J. Watson Jr., Steve 
Wozniak, Steve Jobs, Bill Gates, and 
Marvin Minsky are among the com¬ 
puting pioneers who appear in the se¬ 
ries, which covers the period from 
World War II to the present — from 
ENIAC to virtual reality. 

The five parts, scheduled for con¬ 
secutive weeks, are 

• “Giant Brains,” covering wartime 
events leading to the debut of 
ENIAC; 

• “Inventing the Future,” examining 
the computer’s rise from obscurity 
to prominence in the business 
world; 

• “The Paperback Computer,” relat¬ 
ing how size, affordability, and 
ease of use brought ordinary peo¬ 
ple into computing; 

• “The Thinking Machine,” focusing 
on development of a computer to 
vie with humans in intelligence; 
and 

• “The World at Your Fingertips,” 
exploring the social revolution 
wrought by computers. 

The program was produced by the 
WGBH Science Unit, makers of 
Nova, in association with the British 
Broadcasting Corp. 


The Computer Society Fellows 
Committee encourages society mem¬ 
bers to help deserving colleagues gain 
the recognition that comes with being 
elected to fellowship in the IEEE. 

The committee, which must provide 
evaluations of nominees in the com¬ 
puter field to the IEEE Fellow Com¬ 
mittee, is also prepared to offer advice 
regarding the best ways to promote a 
candidate. Eligibility requirements are 
shown below. 

The fellow grade recognizes unusu¬ 
al distinction in the profession and is 
conferred on a person who has made 
outstanding individual contributions 
in IEEE designated fields. Fellow is 
the highest grade of membership and 
the only grade for which members 
cannot personally apply but must be 
nominated by another member. 

Key to a candidate’s success is a 
crisp statement of accomplishments, 
the evaluation of the appropriate soci¬ 
ety or council, and the selection of 
references who will provide strong en¬ 
dorsements. A candidate must have 
been an IEEE member of any grade, 
including student member, for at least 
five years, and must be a senior mem¬ 
ber at the time of nomination. (Senior 
membership applications received by 
March 26,1992, have a good chance 
for approval prior to the fellows nomi¬ 
nation process.) 

An optional provision allows for en¬ 
dorsements from IEEE entities such 
as sections, chapters, and committees, 
and from non-IEEE entities and non- 
IEEE individuals. Such endorsements 
may be useful when these entities or 
individuals are in the best position to 
provide a credible statement. Nomina¬ 
tors need not be IEEE members, and 
the IEEE Guide for Fellow Grade 
Nominations, included in the nomina¬ 
tion form package, states that nomina¬ 
tions carry no more weight if the nom¬ 
inator is a senior member or a fellow. 
(Members of the IEEE Board of Di¬ 
rectors and the IEEE Fellow Commit¬ 
tee cannot act as nominators or en¬ 
dorsers, however. Members of the 
society evaluation committee cannot 
act as nominators or endorsers of can¬ 
didates they must review.) 


The original typewritten 1992 nomi¬ 
nation form must be received at IEEE 
headquarters by April 15,1992, at 
which time IEEE must also receive at 
least five fellow grade references. In 
addition, by April 15 a copy must be 
received by the evaluating society. 
(Nominations for candidates in the 
computer field must be sent to Merlin 
G. Smith at the address shown below). 

The evaluating society should be 
the one best able to evaluate the can¬ 
didate’s work. If a candidate’s work 
falls under the auspices of two societ¬ 
ies, a nominator may choose the one 
expected to give the best evaluation. 
Evaluation by the Education Society 
may be a beneficial option for educators. 

A nomination package, complete 
with a nominations guide, is available 
from Dolores Wright, IEEE Head¬ 
quarters, 345 East 47th St., New York, 
NY 10017, phone (212) 705-7750, fax 
(212) 223-2911. 

In evaluating the nominations, the 
IEEE Fellow Committee considers 
the following criteria: 

• individual contribution(s) as an 
engineer or scientist, technical 
leader, or educator; 

• technical evaluation by one IEEE 
society/council; 

• tangible and verifiable evidence of 
technical accomplishments, such 
as technical publications, patents, 
reports, published descriptions of 
products, and/or services; 

• confidential opinions of references 
who can attest to the candidate’s 
work (in the US and Canada these 
references should be from IEEE 
fellows; outside the US and Cana¬ 
da, senior members may be used 
as references, if needed); 

• service to IEEE (or AIEE or 
IRE); and 

• total years in the profession. 

For further information, contact 
Merlin G. Smith, IBM T.J. Watson 
Research Center, PO Box 218, York- 
town Heights, NY 10598, phone (914) 
945-1240, fax (914) 945-3780, Comp- 
mail m.smith, Internet 
merlin@ibm.com. 
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Advance Announcement 





The 12th International Conference on 

Distributed 

Computing 

Systems 

Pacific Convention Plaza 
Yokohama, Japan • June 9-12,1992 


his conference encompasses 
the technical aspects of 
specifying, designing, 
implementing, and evalu¬ 
ating distributed computing 
systems. In such systems, there are mul¬ 
tiple processing resources interconnected 
to cooperate under system-wide control 
with minimal reliance on centralized pro¬ 
cedures, data, or hardware. The location 
of computing resources may span the 
spectrum from physical adjacency to geo¬ 
graphical dispersion. 

Join us for ICDCS-12 in the newly opened 
Pacific Convention Plaza in Yokohama, 
Japan, which is just a short train ride 
from Tokyo. 

Keynote Speakers 
Three distinguished speakers are sched¬ 
uled to present keynote addresses at 
ICDCS-12: 

• Professor Raymond E. Miller, 
University of Maryland 

• Dr. Yukio Mizuno, Senior Executive 
Vice President, NEC 

• Professor Hideo Aiso, 

Keio University 

Banquet and Cruise 
A buffet party will be held on June 11 
from 6:00 to 8:00 p.m. at Marine Shuttle, 
which will cruise Tokyo Bay for a 2-hour 
sightseeing tour (the cost is included in 
the conference registration). 


Hotel 

The conference will be held at the Pacific 
Convention Plaza, Yokohama (Pacifico 
Yokohama). A block of rooms have been 
reserved in three hotels in Yokohama for 
the attendees through Japan Travel Bu¬ 
reau, Inc. (JTB). 

Advanced Technology Seminars 
Six half-day Advanced Technology Semi¬ 
nars (four in English and two in Japa¬ 
nese) are scheduled for Tuesday, June 9. 
The morning seminars are S-l, S-2, and 
S-3; the afternoon seminars are S-4, S-5, 
and S-6. 

• S-l: Object-Oriented Database 
Systems: Concepts and Architectural 
Issues, Shojiro Nishio, Osaka 
University (in Japanese) 

• S-2: Distributed Operating Systems, 
Partha Dasgupta, Arizona State 
University (in English) 

• S-3: Distributed Shared Memory, 
Willy Zwaenepoel, Rice University 
(in English) 

• S-4: Computer-Supported Coopera¬ 
tive Work, Shogo Nishida, 

Mitsubishi Electric (in Japanese) 

• S-5: Software Tools for Visualization 
of Parallel and Distributed Programs 
and Systems, Thomas L. Casavant, 
University of Iowa (in English) 

• S-6: Responsive Multicomputer 
Systems, Miroslaw Malek, ONR & 
University of Texas (in English) 


Technical Sessions 

The technical program includes presen¬ 
tations of 85 high-quality papers that 
were selected by the conference program 
committee from 301 paper submissions. 
The technical sessions will include: 

• Software Engineering Applied 

• Transaction Models 

• Communication Architectures 

• Task Scheduling 

• Protocol Conversion 

• Modelling 

• Synchronization Algorithms 

• File Replication 

• Naming 

• Synchronization 

• Protocol Testing 

• Coteries 

• Computer-Supported Cooperative 
Work 

• System Design 

• Distributed Artificial Intelligence 

• Performance Evaluation 

• Decentralized Protocols 

• Distributed Cooperative Control 

• Fault Tolerant Algorithms 

• Software Engineering Theory 

• Concurrency Control 

• Fault Tolerant Interconnection 
Networks 

• Database Reliability 

• Communication Protocols 

• Real-Time Issues 

• Protocol Specification 

For More Information 
Ming T. (Mike) Liu 
Department of CIS 
Ohio State University 
2036 Neil Avenue 
Columbus, OH 43210-1277 
Phone (614) 292-6552 
Fax (614) 292-9021 
E-mail: mike.liu@osu.edu 
OR 

IEEE Computer Society 
1730 Massachusetts Ave., N.W. 
Washington, D.C. 20036-1903 
Phone (202) 371-1013 
Fax (202) 728-0884 
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ICDCS-12 Conference Registration 

Please return registration form to: 

Ms. Noriko Uehara, ICDCS-12 Secretariat, c/o Business Center for Academic Societies Japan 
2nd Floor, Crocevia Hongo BLDG, 3-23-1, Hongo, Bunkyo-ku, Tokyo 113, Japan 
Tel: +81-3-3817-5831; Fax: +81-3-3817-5836; Telex: 02722268 BCJSPJ 

(After April 13, please send in c/o Business Center For Academic Societies Japan, 5-16-9 Komagome, 
Bunkyo-ku, Tokyo 113, Japan; Tel: +81-5814-5800; Fax: +81-5814-5823) 


Please type or print: 

Affiliation_ 

Mailing Address _ 

City/State/Zip/Country_ 

Work Phone_ 

IEEE/CS/IPSJ Membership Number 


Mi 


Fax Number _ 

Email Address 


Conference and Seminar Registration Fees 

Advance Registration (Received by May 11,1992) 

Member Non-Member Student 
Conference only ¥65,000 ¥78,000 ¥20,000 

One Half-day Seminar ¥25,000 ¥30,000 ¥10,000 

Please check the seminar(s) you wish to attend 

O Tuesday Morning, June 9 (Check one seminar) 

□ S-l QS-2 CIS-3 

□ Tuesday Afternoon, June 9 (Check one seminar) 

□ S-4 CIS-5 OS-6 

Seminar Fee(s): ¥_ 

O Wednesday - Friday, June 10-12 
ICDCS-12 Conference 

Conference Fee: ¥_ 

Total Fee: ¥_ 


Late Registration (Received after May 12,1992) 

Member Non-Member Student 
Conference only ¥70,000 ¥84,000 ¥23,000 

One Half-day Seminar ¥30,000 ¥36,000 ¥12,000 

Method of Payment 

O Bank draft for the fee payable to the order of ICDCS-12 

□ Bank transfer through my bank_to the 

account of ICDCS-12 (A/C No. 075-1719752, Daiichi Kangyo Bank, 
Hongo Branch, Tokyo) 

□ Charge registration fee to (except Japanese): 

□ Master Card □ Visa □ American Express □ Diners Club 

Cardholder Name_;_ 

Card Number_Exp. Date_ 

Signature t ': " ; • ~ ~ ~ ~_J2- 


Notes: 

• Payment must be made in Japanese yen. Approximate currency conversion rate is $1=¥130. 

• Refunds will be made if requested in writing no later than May 15; a cancellation fee of ¥5,000 will be charged. 

• Seminar registration fee includes a hard copy of the presentation foils. 

• Conference registration fee includes a copy of proceedings, two reception tickets on Tuesday evening and a hosted Thursday evening party (banquet and cruise). 

• Student registration fee does not include reception and party. 


Hotel Reservations 

Application for accommodations should be sent to the Japan Travel Bureau, Inc. (JTB) no later than April 20 ,1992 with the remittance of a hotel 
deposit in the amount of ¥20,000 per room. No reservation will be confirmed in the absence of a deposit. 


Hotels and Room Rates: 

□ Yokohama Grand Intercontinental Hotel 
(Conference Site) 

1-1 Minatomirai, Nishi-ku, Yokohama 220 
Phone: 81-45-223-2222 

□ Twin with bath: ¥26,000 

□ Single with bath: ¥24,000 


□ Isezakicho Washington Hotel 
5-53 Choja-machi, Naka-ku, Yokohama 231 
Phone: 81-45-243-7111 
Single with bath: ¥9,900* 

1-minute walk to Isezaki-choja-machi 
subway station; 5 minute subway ride and 
10 minute walk from subway 


□ San-Ai Yokohama Hotel 
3-95 Hanasaki-cho, Naka-ku, 
Yokohama 231 
Phone: 81-45-242-4411 
Single with bath: ¥6,800* 
15-minute walk to conference si 


The hotel rate does not include meals or 10% service charge; a 3-6% tax will be added. *Rates include the 10% service charge. 


Send accomodation application to: Japan Travel Bureau, Inc. 

International Travel Division 
Convention Center (Ref. CD6-7301-92) 

1-13-1, Nihombashi, Chuo-ku, Tokyo 103, Japan 
Phone: +81-3-3276-7885 
Fax: +81-3-3276-7806 or +81-3-3271-4134 
Telex: TOURIST J24418 
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Word processors — for better or for worse 


The reverence with which most us¬ 
ers regard word processors is legend¬ 
ary. Each of us has a litany of reasons 
why the one we use is best — and why 
we would never consider anything 
else. This month’s column presents 
some definitely biased views from re¬ 
viewers about their word processors 
of choice. 


Ami Pro 2.0 

If I could have only one program on 
my PC, it would be my Ami Pro word 
processor. I constantly use this versa¬ 
tile performer for writing letters, 
drafting memos, and creating exams. 
Its features make these daily activities 
fun and efficient. The package also 
promises more productive use of my 
time through its rich array of new fea¬ 
tures. 

I prefer Ami Pro over the competi¬ 
tion because it is intuitive and easy to 
use. In the past, these features were 
almost a necessity because the docu¬ 
mentation was terse at best. But the 
manual that comes with version 2.0 is 
completely redone and crammed full 
of text, helpful hints, and even exam¬ 
ples. In addition, several shorter 
booklets provide a basic tutorial, a 
user guide to Adobe Type Manger 
(now included with Ami Pro), an in¬ 
stallation guide, and a stylesheet 
guide. 

Installation continues to be easy 
and automated. If you install Ami Pro 
with options, you can include or omit 
such features as charting, drawing, 
and editing equations and dialogue. 
Depending on use, you can fill from 5 
to 9 Mbytes of disk space with these 
features. The recommended system 
for Ami Pro is a 386 with 2 Mbytes of 
RAM. 

Version 2.0 features include 

• a collapsible click-and-drag outlin- 

• “power fields” like that can be in¬ 
serted into the main document text to 
automatically perform such tasks as 


numbering sequences or integrating 
macro language statements; 

• macros that run when you open a 
file; 

• a master document for compiling 
“books” from separate chapters; 

• password protection for docu¬ 
ments; 

• a status bar at the bottom of the 
screen that lets users select styles, 
fonts, and point sizes from pop-up 
menus; change the mode from insert 
to overtype to revision formats; show 
or hide smart icons; and move be¬ 
tween pages; 

• the capability to have multiple 
documents open at the same time; 

• new OLE (object linking and em¬ 
bedding) and improved DDE (dynam¬ 
ic data-exchange) support; 

• enhancements to the macro lan¬ 
guage; 

• an equations editor for creating 
and editing scientific and mathemati¬ 
cal equations, including inserting Tex 
(TgX) statements directly into an 
equation or formula; 

• revision-marking and document- 
comparison capabilities; 

• customizable smart icons that can 
appear at the top, bottom, left, or 
right of the display — or float; 

• improved table features and 
frames; and 

• more filters for importing and ex¬ 
porting documents created in other 
formats. 

Surprisingly, you get all of this with 
improved performance over the last 
release. 

Many of these features are impor¬ 
tant to me. For instance, in version 
1.2, you had to change the printer set¬ 
up to go from portrait to landscape 
mode. Now the page orientation is 
stored with the document. Frames can 
be configured with rounded or square 
corners and shadows. You can also 
choose inches or centimeters and pi¬ 
cas or points as page and type specifi¬ 
cations. I also like that the right 
mouse button reminds me what a 
Smartlcon does. Then, too, the revi¬ 
sion-marking and notes features fit 


well into my environment when I want 
to share a document with other users 
and know what has changed or leave 
a note on why something was done. 
The simplicity of changing styles, 
fonts, and point sizes makes it easy 
to adjust my documents to fit a partic¬ 
ular page size. 

I don’t think you could find a more 
satisfied user than me when it comes 
to Ami Pro. For $495 (or $95 for an 
upgrade), I recommend this word pro¬ 
cessor to everyone who asks me what 
word processor to buy. 

Readers can contact the Lotus De¬ 
velopment Corp. Word Processing Di¬ 
vision at 5600 Glenridge Dr., Atlanta, 
GA 30342, (404) 851-0007; or circle 
Reader Service Number 21. 

— Richard Eckhouse, University of 
Massachusetts at Boston 


Word for Windows 2.0 

The reviews of this package have al¬ 
ways been unanimously positive. My 
views are not quite so favorable. I ap¬ 
plauded the first version and have 
never regretted leaving my DOS word 
processor for the “GUIness” of Win¬ 
Word. For more than a year I worked 
with the package daily, learning the 
peculiarities of its wealth of functions 
— and not learning or needing many 
others. Then, along came version 2.0 
with even more functions and many 
so-called “improvements” — just 
when I had learned how to do things 
the old way. 

Don’t get me wrong. Most of the 
new functions really are improve¬ 
ments. For example, you can highlight 
text and drag it to a new location with 
the mouse. No one ever tells you this, 
but the text doesn’t actually “drag.” 
The cursor changes shape when it is in 
cut-drag-insert mode. When you re¬ 
lease the mouse button, voila, your 
cut is pasted! This took some getting 
used to. I frequently cut and pasted 
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when I wanted to highlight — but the 
undo function usually fixed every¬ 
thing. 

The great new goodies in version 
2.0 include faster functioning, a handi¬ 
er help function, a more convenient 
spell checker, and more efficient 
printing and file accessing. An icon 
automatically searches your document 
for an address and prints it (properly 
formatted!) on an envelope. You can 
also automatically add bullets or num¬ 
bers to items in a list. 

There is a grammar checker (Cor- 
rectText Grammar Correction from 
Houghton Mifflin) that compares very 
favorably with the one from Gramma- 
tik. In addition to providing grammar 
checking and readability indexes, this 
tool tells you how many characters 
and words your document contains. 
Strangely, those statistics don’t coin¬ 
cide with the ones provided by Word’s 
built-in Summary option. The package 
also includes a fantastic in-line WYSI¬ 
WYG equation editor from Design 
Science. Both these features are well 
integrated with the Word option 
menus. However, the Draw object¬ 
drawing program is a truly crummy 
addition. This module’s abysmal per¬ 
formance and function limitations 
make it almost impossible to use. 

On a happier note, table creation is 
much easier in this version because 
you can do it from the tool bar. How¬ 
ever, it is a real pain to specify line 
definitions for such things as table 
borders. You can also use an icon to 
create graphs with the tables or the 
DDE link to Excel. Another real im¬ 
provement is column creation. The 
Microsoft person who designed the 
previous version’s method for creating 
columns is now probably working for 
Ashton-Tate (remember them?). This 
version has it right. You can easily set 
columns from a tool-bar icon. 

WinWord Version 2.0 is a huge pro¬ 
gram. It took me more than an hour 
to find the 15-Mbyte space on my 
hard drive needed for installation. 
Also, installation problems can occur 
on systems running the software 
Stacker TSR. Even in execution, I en¬ 
countered a number of strange error 
conditions that forced me to exit and 
restart the program. The most com¬ 
mon messages told me I didn’t have 
enough memory on my machine. This 
is particularly irritating when you 
have 6 Mbytes of RAM. 

This new version really has too 
many functions. In fact, there are 
more functions than can be easily doc¬ 
umented. For example, there are new 
icons for viewing your document in 
various sizes. As in the previous ver¬ 


sion, there are also menu options for 
viewing your document in different 
formats. Some features require that 
your document be in a particular view 
mode to operate. I can’t understand 
why I have to remember such non¬ 
sense. Some functions are so complex 
that despite considerable time and ex¬ 
perimentation, I still have not been 
able to use them. For example, I have 
never been able to figure out how to 
place an object at the bottom of a 
page and have that object retain its lo¬ 
cation as I enter text above it. 

I certainly hope that Microsoft 
doesn’t rest on its laurels with this re¬ 
lease of Word. Although the package 
provides many great functions, a lot of 
things still need fixing. I am looking 
forward to the next coming. 

The package costs $495 ($129 for an 
upgrade). 

Readers can contact the Microsoft 
Corp. at 1 Microsoft Way, Redmond, 
WA 98052-6399; (206) 882-8080; or 
circle Reader Service Number 22. 

— Sorel Reisman, California State 
University at Fullerton 


WordPerfect for Windows 

WordPerfect has opened another 
“window” into word processing and 
desktop publishing with its newest 
version of WordPerfect, which runs 
under Windows 3.0. Making full use 
of the GUI environment provided by 
Windows, WordPerfect has smoothed 
out many rough edges characteristic 
of its DOS counterpart. 

The fun begins right at the installa¬ 
tion stage. More options have been 
added to a much-improved installa¬ 
tion program, allowing better custom¬ 
ization for the user. Whenever the 
user needs to make a choice, neces¬ 
sary help text is displayed along with 
the 800 number of the WordPerfect 
help line shining at the top of the 
screen. The installation itself is more 
intelligent and can make certain 
choices, although these choices have 
to be confirmed by the user before 
they can be executed. For example, 
while the DOS version copied all the 
video drivers onto the hard disk and 
let the WordPerfect program choose 
the correct driver, WordPerfect for 
Windows attempts to determine the 
video hardware and copies only the 
necessary drivers to the hard disk. 
And it also asks users if they want the 
other drivers to be copied anyway and 


informs them how much extra disk 
space it will cost. 

Experienced users will take little 
time switching to the new version be¬ 
cause it allows a choice between the 
familiar WordPerfect keystrokes (like 
Alt-F4 for marking a block) or the 
Windows keystrokes (like Alt-F4 for 
closing the window). A keyboard defi¬ 
nition file also emulates WordPerfect 
5.1 for DOS commands plus a number 
of functions through Ctrl-Shift and 
Alt-Shift key combinations. 

A new WYSIWYG feature allows 
users to see all fonts, equations, and 
graphics on screen as they will be 
printed. However, this mode has a 
slow screen-refresh rate that increases 
editing time. This is compensated for 
by the draft mode, which works the 
same way as in the DOS version 
(showing blank boxes for the graph¬ 
ics). Hopefully, the new Windows 3.1 
will provide a better screen-refresh 
rate. Users can import a variety of 
graphical formats into their docu¬ 
ments, including Windows’ metafiles 
and bitmaps. 

Common edit functions appear on 
the screen as a button bar that can be 
displayed on the bottom, left, and 
right sides of the editing window. The 
default bar contains 10 buttons, but 
users can easily modify it to show 
their favorite functions as text, illus¬ 
trations, or a combination. A ruler is 
also provided. 

Documents can be printed through 
the Windows printer drivers. Howev¬ 
er, WordPerfect for Windows has its 
own printer drivers that allow users to 
choose from a larger number of print¬ 
ers than the Windows 3.0 library con¬ 
tains. WordPerfect drivers are also 
much faster than Windows drivers. 

WordPerfect for Windows comes 
with a handy file manager that makes 
file management a breeze. Frequent 
tasks like file copy, rename, delete, 
word search, and quick list show up as 
buttons on the screen. A separate 
window is opened for each level to list 
files in the current subdirectory. This 
file-viewing capability has been ex¬ 
tended to other WordPerfect packag¬ 
es. So now if the user wants to view a 
.wpg file, WordPerfect will recognize 
it as a DrawPerfect file and (if avail¬ 
able) will start DrawPerfect and load 
the specified file. 

Spell and Thesaurus are available as 
separate applications that can be run 
inside or outside WordPerfect. In the 
latter case, a window is opened for ev¬ 
ery new word chosen, showing its syn¬ 
onyms and antonyms, and the user 
can browse in these windows for the 
“perfect” word. 
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Conversion of documents prepared 
with the DOS version is simply not re¬ 
quired because the two versions are 
fully compatible. The only difference 
is the powerful new macro language 
of WordPerfect for Windows, which 
also allows the macros to be edited as 
WordPerfect documents. A utility 
program converts the macros created 
for the DOS version. 

The strongest feature of any Word¬ 
Perfect software has been its help 
function. In the Windows version, on¬ 
line help is provided as an alphabeti¬ 
cal index arid a glossary. Context-sen¬ 
sitive help is available at any editing 
stage. A “what does it do?” feature 
lets users point and shoot from a list 
of editing functions and receive help. 
Telephonic help is also available for 
problems like installation and printer 
drivers. 

The minimum requirements are a 
286 machine with 2 Mbytes of RAM. 
However, for better performance, a 
386 PC with at least 4 Mbytes of RAM 
is recommended. A hard disk, a flop¬ 
py disk drive, a mouse, and MS Win¬ 
dows 3.0 are also required. 

Current users of WP 5.1 for DOS 
can upgrade to the Windows version 
for $99, while new users can get it for 
a list price of $495. 

Readers can contact the WordPer¬ 
fect Corp. at 155 N. Technology Way, 
Orem, Utah; (800) 451-5151; or circle 
Reader Service Number 23. 

— Faisel Saeed, Oklahoma State 
University 


EXP 

Because of shrinking technical sup¬ 
port services at many institutions, a 
technical word processor is becoming 
more of a necessity than a luxury. 
Choosing the right one, however, is 
difficult. My choice is EXP, the Scien¬ 
tific Word Processor from Brooks/ 
Cole at $295. 

Installation is fully automated. My 
one problem was selecting the right 
video card when mine wasn’t listed on 
the menu. When I guessed wrong, I 
had to install EXP all over again! A 
discussion in the installation section 
of the manual about compatibility be¬ 
tween various video cards (and print¬ 
ers) would have helped. 

EXP comes with two documents; 
the standard EXP manual and a sec¬ 
ond document called EXP Express. 
The manual is written primarily as a 
reference book for someone who al¬ 
ready understands how to use the 


package. Consequently, I relied on 
EXP Express. 

When you start the program, you 
see a typical word processing screen: a 
status line at the top of the screen 
(page, line, document name, and so 
on), and a large window that holds 
your text. On closer inspection, how¬ 
ever, there is a line between the status 
line and the main screen. This prompt 
line is where you enter format com¬ 
mands and all special EXP commands 
to produce technical symbols. 

The program has all the usual fea¬ 
tures one expects in a quality word 
processor. You can set margins, line 
spacing, tabs, top of page, bottom of 
page, etc. You can produce headers, 
footers, footnotes, underlines, sub¬ 
scripts, and superscripts, etc., as well 
as columnar printing. A spelling 
checker and a macro editor are in¬ 
cluded, and EXP can import PCX and 
TIFF graphics files. Seven basic text 
fonts are available. While this list is 
somewhat short for a word processor, 
it is quite adequate for the technical 
variety. 

Obviously, you buy a technical 
word processor to produce technical 
symbols. When I looked over the list 
of available symbols, I couldn’t think 
of a single missing symbol. However, 
if you want a symbol that does not 
come with the package, a font devel¬ 
opment kit is available for $150. 

To enter a particular symbol into a 
document, you simply hit the FI key, 
which puts the cursor up on the 
prompt line, then type the name of 
the symbol, and hit Enter. The symbol 
appears on the screen exactly as it will 
appear in your printed text. Yes, EXP 
is WYSIWYG. 

But how do you know the name of 
the symbol? Most of them are obvi¬ 
ous. If you know the usual name for 
the symbol, that is probably also the 
EXP prompt name for it. What about 
more complicated expressions that 
combine several symbols? This re¬ 
quires the notion of a box, a construc¬ 
tion that is really central to using this 
processor. 

A box is an entity containing sym¬ 
bols that are strung together. You can 
put boxes within boxes, which is how 
you build up complicated expressions. 
For example, the symbol x 2 is an x fol¬ 
lowed by a superscript box containing 
a 2. I could write this symbolically as 
‘x [2]’ where [ ] denotes the super¬ 
script box containing the 2 (actually 
EXP uses the symbols [ and ] as con¬ 
trol codes to represent a box). To pro¬ 
duce the example at hand, you first hit 
the FI key, which puts you on the 
prompt line, then type \ x sp 2’8 cl, 


and hit Enter (actually, you don’t 
have to type the \; EXP puts it there 
for you). The \ symbol tells the pro¬ 
gram that what follows are either 
commands or italic symbols. The x 
separated by a space on either side 
tells the program that this is an italic 
symbol and not a command; com¬ 
mands contain more than one symbol. 
The next entry ‘sp’ is a command that 
tells the program to open up a super¬ 
script box (you can think of this as the 
[ symbol). The notation 2’8 tells EXP 
to print the 2 in 8-point size and ‘cl’ 
tells the program to close the box (the 
] symbol). When you hit Enter, x 2 ap¬ 
pears in your text. A more complicat¬ 
ed expression, namely 



would have the symbolic form [ x [su¬ 
perscript 2 box] + 1], where the outer 
box represents the radical. The com¬ 
mand you would enter on the prompt 
line to produce this expression is \ op 
x sp 2’8 cl + 1 sqr. Here ‘op’ opens the 
outer box, the next four symbols pro¬ 
duce the x squared as described, + and 
1 are single characters, and sqr is a 
command that closes the outer box 
with a radical. The logic of boxes is 
very similar to the use of parentheses 
in mathematics, which is why the no¬ 
tation ‘[ ]’ for a box is good. 

I have a couple of minor criticisms 
of the product. On p. 26 of EXP Ex¬ 
press , the author makes a big fuss 
about the fact that hard spaces (spaces 
that have fixed width and are not af¬ 
fected by justification) should always 
be used in boxes. It is explained that 
you can get a hard space by using Ctrl 
S instead of Space, leaving the reader 
with the impression that Ctrl S should 
work on the prompt line. It doesn’t! 
Instead you have to enter the lengthy 
command ‘hard-space’ on the prompt 
line. An alternative to this uses so- 
called piecemeal entries on the 
prompt line (p. 31), but I haven’t time 
or space here to go into that. Anyway, 
it’s a shame that Ctrl S doesn’t work 
on the prompt line. I also felt that the 
explanation of how to obtain the con¬ 
figuration 

formula 

second formula J 

as discussed on p. 32 is woefully inade¬ 
quate. It takes some experience to 
know that the following string of com¬ 
mands produces the above configura¬ 
tion: \ op \ formula \ cl rug \ second \ 
hardspace \ formula \ bra. 

Finally, you will find the Shift FI 
command extremely useful when 
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learning EXP. This command moves 
the cursor to the prompt line and re¬ 
produces for editing the last string of 
commands previously entered. I used 
this feature repeatedly. 

EXP is an excellent technical word 
processor. The printed output is beau¬ 
tiful, even if you don’t have a fancy la¬ 
ser printer. In spite of all this, there is 


a possible problem. The American 
Mathematical Society has decreed 
that submitted papers should be done 
in PC Tex, making it the standard in 
the mathematical world. How de¬ 
pressing! Fortunately the publisher of 
EXP has a $250 EXP-to-Tex conver¬ 
sion utility. And that, as far as I am 
concerned, settles the issue. 


Readers may contact the Brooks/ 
Cole Publishing Co. at 511 Forest 
Lodge Rd., Pacific Grove, CA 93950- 
0728; (408) 373-0728; fax (408) 375- 
6414; or circle Reader Service Number 
24. 

— Donald E. Catlin, University of 
Massachusetts at Amherst 


Highly innovative products 


Two very different innovative prod¬ 
ucts caught my attention at Fall Com¬ 
dex. One was the Flashdrive from 
BSE, and the other was the 5 x 5-inch 
graphics tablet from AceCAD. Each 
represents a well-thought-out design 
that fits a particular niche in the mar¬ 
ket better than any other product I 
have come across. 


Flashdrive 25 

This compact, portable IDE 2.5- 
inch hard-disk system takes advantage 
of CMOS LSI to put up to 60 Mbytes 
in an instrument case that measures 
only 1.5 x 5 x 5 inches and weighs 
approximately two pounds — includ¬ 
ing NiCad batteries! Since the PC 
interface is via the parallel port 
and a device driver installed in the 
CONFIG.SYS file, any computer — 
from palmtop to desktop — can be 
used with the Flashdrive. While the 
parallel port is not as fast as the PC 
bus, transfer rates are respectable 


(500 Kbaud) and actually improve 
with higher speed PCs due to a pro¬ 
prietary disk controller and inventive 
software. 

The Flashdrive seemed the perfect 
addition to my T1000 laptop with its 
single 720-Kbyte floppy drive. Every¬ 
thing I wanted in the way of DOS sys¬ 
tems would fit on the 20-Mbyte drive 
BSE provided for testing, and I could 
now easily boot from either the built- 
in Version 2.1 of DOS or Version 5.0 
on the Flashdrive. So I hooked the 
drive to my desktop to initially load 
the software and immediately discov¬ 
ered the obvious: I now had the per¬ 
fect solution for transferring large 
programs between machines without 
the hassle of dealing with a large col¬ 
lection of floppies. Since the drive is 
self-contained and battery life is esti¬ 
mated at 4 to 5 hours during average 
use, moving the Flashdrive between 
machines is quick and easy. Also, the 
drive’s design does not require the 
parallel port to be dedicated to the 
unit. A second 25-pin connector on 


the unit means whatever was on the 
port can remain connected. 

There are two ways to buy the 
drive: bare or with a hard drive in¬ 
stalled. List price for the unit alone is 
$199, including the external power 
supply, parallel cable, software, and 
controller. For $399, you can have the 
20-Mbyte drive like the one I tested. 
Two instruction manuals cover instal¬ 
lation and software setup. Software 
installation is automatic, with a manu¬ 
al override to specify the power-down 
delay (to turn the drive off when not 
used for some number of seconds) 
and the parallel port address. A disk¬ 
drive-partitioning utility is included 
for those using older versions of DOS 
with 32-Mbyte partition-size limita¬ 
tions. Although on-the-fly data-com- 
pression software is available, I didn’t 
test it. 

The Flashdrive has breathed new 
life into owning a laptop. Gone are 
the days of dragging numerous flop¬ 
pies around on trips. Instead, I have a 
unit that easily fits into my carrying 
case without adding appreciable 
weight. Now, if only the battery in the 
Toshiba would last as long as it does 
in the Flashdrive. . . . 

For those willing to give up battery 
power, the Flashdrive 35 handles 3.5- 
inch drives of up to 750 Mbytes. For 
$499, you can get one with a 40-Mbyte 
drive. 

The Flashdrive (tested and ap¬ 
proved by Toshiba, NEC, Poquet, 
Atari, and Eckhouse) is compatible 
with DR DOS, most networks, Win¬ 
dows, and all versions of MS- and PC- 
DOS 3.0 and above. It worked fine 
with DOS 2.1 in my T1000 and was 
compatible with all DOS utilities in¬ 
cluding Format and Chkdsk. 

Readers can contact BSE at 1622 
Edinger Ave., Suite F, Tustin, CA 
92680; (714) 258-8722; or circle Read¬ 
er Service Number 25. 

— Richard Eckhouse, University of 
Massachusetts at Boston 
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Acecat 

The second product that stood out 
at Comdex was AceCAD’s graphics 
tablet, called the Acecat (pun intend¬ 
ed). Normally I don’t care much for 
tablets because they take up too much 
desk space, are clumsy if you have to 
move them around, and are a lot more 
expensive than my personal favorite, 
the trackball. But the compact design 
of the 5 x 5-inch Acecat unit, which 
you can hold in one hand while draw¬ 
ing with the other, has changed my 
mind. 

Actually, this ergonomic tablet is 8 
inches wide by 9.5 inches high but 
weighs only 1.2 lbs. A two-button pen 
is normally supplied, but you can ex¬ 
change it for an optional two-button 
puck. The technology used is induc¬ 
tive, and a green LED at the top of 
the tablet tells you when you are out 
of range. The interface to the PC is 
via the serial port, with power for the 
tablet coming from the keyboard us¬ 
ing the supplied adapter cable (stan¬ 
dard or optional PS/2 mini-DIN). An 
optional power supply is available for 
laptops or desktops without detach¬ 
able keyboards. While this review is 
about the PC version of the tablet, 
there is a version available for the 
Mac as well. 

Resolution is 1,000 lines per inch, 
and the tablet can be switched from 
mouse (relative) to tablet (absolute) 
mode by toggling a switch located at 
the top of the tablet. A thorough man¬ 


Review notes 

Productivity boosters. Ever wanted 
your PC to talk like a Mac? Or pro¬ 
vide scrolling for a virtual desktop 
four times bigger than that of Win¬ 
dows 3.0? Aristosoft’s latest entries in 
the burgeoning Windows 3.0 accesso¬ 
ry market, Wired for Sound and 
MoreWindows, do just that. While 
many of the so-called productivity 
boosters for Windows turn out to be 
little more than gimmicks, MoreWin¬ 
dows and, to a lesser extent, Wired for 
Sound, are truly useful. 

MoreWindows, retailing at a hefty 
$99.95, provides a special display driv¬ 
er to make Windows think that your 
desktop is much bigger — 1,024 x 
1,024 instead of 640 x 480. You access 
parts of this virtual desktop simply by 
moving the mouse to the edge of the 
screen, which causes the displayed 
window to rapidly scroll to the new 
position. With this utility, I had full¬ 


ual and a quick-start flyer explain op¬ 
erating theory and how to connect ca¬ 
bles and copy the drivers onto your 
system. The drivers include mouse, 
AutoCAD, Windows, and Summa- 
graphics MM961 modes. A Windows 
tablet control panel allows customiza¬ 
tion of the device with such features 
as button assignments, absolute/rela¬ 
tive modes, tracking area, units, and 
resolution. 

Direct contact with the tablet sur¬ 
face is not required. This lets you 
trace, draw, map, or select items from 
a template lying between the tablet 
and the pen. But you do have to be 
careful, because the pen is sensitive to 
movement up to 1/4 inch away from 
the surface. If you inadvertently pull 
away from the tablet while moving an 
object, the tablet might move as well. 

I tried the tablet with all kinds of 
software, sometimes using the mouse 
mode and other times the tablet 
mode. It took a few minutes for me to 
learn to use a pen rather than a 
mouse, but the convenience of tablet 
mode is clearly evident. In particular, 

I used Acecat with CAD and forms 
programs where the ability to point, 
click, move, draw, etc., was natural — 
and faster than with a mouse. The 
same can be said about paint pro¬ 
grams where the tablet mimics the pa- 
per-and-pencil-tools metaphor we are 
accustomed to in free-form drawing. 

One problem I did find was that the 
Acecat driver for Windows supports 
only the tablet mode. This means that 



The Acecat graphics tablet. 


DOS applications running in a win¬ 
dow cannot use the tablet as a mouse. 
Fortunately, the people at AceCAD 
told me there is third-party software 
available for the users who have re¬ 
quested it. They also said there would 
be an Acekid version of the tablet 
specifically designed for the younger 
set tuned into computers and graphics. 

I’ve saved the best part for last and 
that is the $129 price. Now you CAD 
users can have a particularly valuable 
alternative to a mouse or trackball. 

Readers can contact AceCAD Digi¬ 
tizers at PO Box 431, Monterey, CA 
93942-0431; (800) 676-4223; or circle 
Reader Service Number 26. 

— Richard Eckhouse, University of 
Massachusetts at Boston 


sized Program Manager, Procomm+, 
DOS, and Paintbrush Windows open, 
almost without overlapping each oth¬ 
er! The need for endless iconizing or 
stacking of Windows is greatly re¬ 
duced, and interwindow cutting and 
pasting is much easier. 

Options for portrait, landscape, and 
paper-white displays are also avail¬ 
able. But I found the square color op¬ 
tion to be the most useful. Yet More¬ 
Windows has a few pitfalls. It requires 
300 Kbytes of extended memory to 
run in full-color 1,024 x 1,024 mode. 
And since Windows likes to center di¬ 
alogue boxes in the middle of the 
screen, you may miss them unless 
your scrolling region is centered. And 
many applications (like Paintbrush or 
Excel) try to make themselves as large 
as the whole screen, 1,024 square. 
However, resizing the window quickly 
cures that. These minor complaints 


aside, you will be impressed with this 
utility’s speed and the advantages of a 
bigger workspace. 

Aristosoft’s other offering, Wired 
for Sound, also provides all it claims, 
turning your PC into a true Mac-like 
purveyor of auditory stimulation. 
While this $39 application doesn’t 
have great bearing on how much 
you get done during the day, it does 
add a playful side to your dialogue 
boxes, error boxes, and system activi¬ 
ty. Using the PC’s internal speaker 
to play digitally sampled sounds, the 
package wrenches the highest fidelity 
I could expect out of my dinky speak¬ 
er. 

Want a screeching crash to accom¬ 
pany your UAEs? How about a Tar- 
zan yell to tell you the printer is out of 
paper? Wired for Sound has these 
sounds and 50 others to keep you en¬ 
tertained for hours. It is customizable, 
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too, so you can assign sounds to non- 
system-related events in your Win¬ 
dows applications. Assigning sounds 
to a given event is a simple process of 
clicking on the sound and the event to 
match. There is a preview capability, a 
volume control, a talking clock/ap¬ 
pointment book, and even special 
sounds to go with the After Dark 
screen-saver package. Be aware, how¬ 
ever, that there is only so much ampli¬ 
tude you can get from a 2-inch speak¬ 
er, and if your machine sits anywhere 
but on top of your desk, hearing 
Wired for Sound is difficult. Further¬ 
more, it does not run in Windows’ real 
mode. 

Both programs come with Win¬ 
dows-driven installation programs, 
making installation easy. They have 
Windows 3.0-based hypertext help, 
covering for the flimsy 15-page manu¬ 
als that come in the box. No informa¬ 
tion about SoundBlaster support was 
mentioned in the Wired for Sound 
manual, though later versions claim to 
support it. I ran both programs on my 
386 at work and 286 at home with no 
difficulties, other than noticing that 
my clone’s speaker at home was sig¬ 
nificantly louder that the Everex 
speaker at the office. 

If you love adding new environ¬ 
ment-enhancing tools to your Win¬ 
dows sessions, these two are for you. 
They’re fun and will draw a crowd 
around your desk when you install 
them. But if you just want enhanced 
scrolling power and can rely on tele¬ 
phones and coworkers for noise, skip 
Wired for Sound. 

Readers can contact Aristosoft Inc. 
at 6920 Roll Center Pkwy., Ste. 209, 
Pleasanton, CA 94566; (510) 426-5355; 
fax (510) 426-6703; or circle Reader 
Service Number 27. 

— D. Noah Eckhouse, MIT 


MathType for Windows. This equa¬ 
tion editor from Design Science is one 
of a new breed of products available 
for use with MS-DOS Windows 3.0. 
This generation of software lets users 
take advantage of the full capability 
of the Windows system, letting them 
create, edit, and use mathematical 
proofs and formulas. The formula 
primitives can be used within the do¬ 
main of most calculuses for most of 
the practical mathematical universes. 
Of course, as a Windows 3.0-compati- 
ble program, MathType provides all 
the benefits inherent in a windowing 
system. 

MathType includes a variety of 


fonts and provides WYSIWYG for¬ 
mulas. Custom fonts, as well as other 
extended features, can be installed at 
any time. Most Windows word proces¬ 
sors are supported (in fact, Design 
Science has licensed a version of 
MathType, named Equation Editor, 
to Microsoft for inclusion in Word for 
Windows 2.0, as discussed in a previ¬ 
ous review in this month’s column). A 
formula can be transferred from a 
MathType page to any Windows-com¬ 
patible program through the clip¬ 
board. Similarly, the formulas and 
proofs that are created can be printed 
on an appropriately supported printer 
where the information is stored in an 
intermediate language: Window 
Graphics Metafile, Encapsulated 
PostScript, or Tex. To enable 
WYSIWYG printing, the printer must 
be compatible with one of these for¬ 
mats or with a printer support pack¬ 
age such as Adobe Type Manager. 

These formulas can be manipulated 
and maintained with ease due to 
MathType’s macrofunctions designed 
to create equations with an expanded 
character set that provides all the nec¬ 
essary elements. The extensions allow 
users to manipulate most mathemati¬ 
cal symbols, inserting and altering 
symbol usage by means of pull-down 
menus. Most users can quickly write 
any formula or proof to use in creat¬ 
ing quality documents. 

Because the program is fully cus¬ 
tomizable, users can adjust, change, 
add, and delete any number of fea¬ 
tures. The most obvious are the dis¬ 
play and printer fonts. In addition, 
functions and display primitives can 
be defined and added to the menuing 
system. Windows 3.0 compatibility al¬ 
lows users to manipulate screen posi¬ 
tioning, size, and color. 

This $249 program runs on an IBM 
PC with a minimum memory of 640 
Kbytes and requires 2 Mbytes on the 
hard disk. A mouse and an EGA 
monitor are also required. 

Readers can contact Design Science 
at 4028 Broadway, Long Beach, CA 
90803; (213) 433-0685; or circle Read¬ 
er Service Number 28. 

— Ed Gordon, Bdata Systems 


Laptop UltraVision. The biggest re¬ 
maining difference between the ma¬ 
chine you leave on your desk and the 
machine you travel with is the screen 
quality. The cheapest desktop clones 
have CRTs that far outshine laptop 
displays in speed, size, clarity, and 
contrast. Now, Laptop UltraVision 


goes a long way toward making up for 
the deficiencies. In fact, this package 
from Personics is the best thing that 
has happened to laptop screens. 

This new version works with flat 
VGA and EGA screens, whether they 
are LCD, gas plasma, or active matrix. 
The software speeds up screen writes 
by replacing ANSI.SYS with its own 
screen drivers, which increase the us¬ 
able screen area by using all scan lines 
for text. Traditional VGA uses 640 x 
400 for text; UV uses 640 x 480. Be¬ 
cause there is less dead space at the 
top and bottom, the text is more read¬ 
able. Screens may be 80 x 25, 34, 50, 
or 60 characters in VGA, and 80 x 25 
or 43 in EGA. Clarity is increased by 
a larger choice of fonts, available in 
all screen sizes. The 20 fonts include 
the usual roman and sans serif. Couri¬ 
er for better readability, and fonts like 
Broadway, Data, and Old English for 
fun. These fonts are usable inside 
most text-based applications. This 
means that you can use WordPerfect 
in 80 x 50 mode with Times Roman 
characters. With a high-quality LCD 
screen, such as a Compaq SLT-20, this 
combination is very readable. 

Laptop UltraVision also gives you 
control over another weakness of lap¬ 
tops — displaying gray scale. PC ap¬ 
plications for color monitors often fail 
to work well on gray-scale displays 
that map colors randomly. This map¬ 
ping may lead to a color application 
using light gray on white on your lap¬ 
top. Gray-scale control lets you dis¬ 
play black on white for readability. 

If you have ever lost your cursor on 
the laptop screen, you’ll appreciate 
the tall, blinking block cursor, which 
is theoretically immune to other appli¬ 
cations’ attempts to change it. 

This $69.95 package uses 16 Kbytes 
of RAM on portables that have VGA 
displays and 9 Kbytes on those with 
EGA displays. These can be loaded 
into high memory with the right tools. 

Readers can contact Personics at 63 
Great Rd„ Maynard, MA 01754; (508) 
897-1575; or circle Reader Service 
Number 29. 

— Quentin Fennessy, ITP Systems 


WinSpeed from Panacea. With all 
the new display adapters coming out 
that have hardware assists, I won¬ 
dered just how well a software-only 
product could do. When I heard about 
a video performance booster for Win¬ 
dows called WinSpeed, I became very 
interested. Besides, what did this com¬ 
pany know that the board manufac- 
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turer didn’t? The answer seems to be 
plenty. 

My testbed was a PC-Genius 486/33 
with 8 Mbytes of RAM and an STB 
Ergo display adapter running in 1,024 
x 768 with 256 colors. I had been very 
pleased with this setup and had in¬ 
stalled STB’s RAM BIOS software to 
eke out every bit of performance. 
Given this, my first question was how 
to measure performance. I turned to 
PC Magazine Labs for their Winbench 
Version 2.0 graphics performance test 
that would measure (1) bitblt opera¬ 
tions using various alignments; (2) 
draw partial and full arcs, lines, poly¬ 
gons, and rectangles; (3) test image 
fonts, (4) test set/query position and 
stretch/compress bitblt; and (5) create 
and delete dialogue boxes. 

The results were impressive. Perfor¬ 
mance ranged from 1,100 percent bet¬ 
ter (memory-to-memory raster ops) to 
22 percent worse (drawing arcs), but 
was often several hundred percent 
better on average. Displaying fonts 
and scrolling are common for all of us, 
and on average the results were 80 
and 51 percent faster, respectively. So 
I dropped the standard display-driver 
software and started using WinSpeed. 
Also, thanks to the benchmarks, I 
found that loading STB’s BIOS in 
RAM really didn’t improve things at 
all! 

Now there is a catch. To gain this 
performance, WinSpeed requires at 
least 512 Kbytes of memory on the 
video board, a Tseng Labs ET-4000 
chip, an ATI Wonder Rev 4 or greater 
(also Wonder-i- and Wonder+ XL), a 
Video 7 VGA or Paradise board, or a 
Trident 8800/8900/9000 VGA board. 
Also, WinSpeed only works in 256- 
color mode (stealing one of these 
modes to gain performance) in 640 x 
480, 800 x 600, or 1,024 x 768 resolu¬ 
tion. 

Installing the software wasn’t hard, 
but the manual and the Read.me file 
did not correspond to the automatic 
installation. However, if you have 
ever modified Windows’ Setup.inf file 
so that you don’t need to keep that 
file around for each set of drivers, 
then it is really quite easy to install 
the drivers and grabber files manually. 
And you may want to adjust your col¬ 
or scheme, since it will be changed 
once you start using this software. 

For $79, this is an inexpensive way 
to get more performance out of your 
old display adapter before shelling out 
$300 or more for a newer one. While I 
was writing this review in Ami Pro 
with WinSpeed, I was immediately im¬ 
pressed with the improved perfor¬ 
mance. 


Readers can contact Panacea Inc. at 
Post Office Square, Ste. 4, 24 Orchard 
View Dr., Londonderry, NH 03053- 
3376; (800) 729-7420; or circle Reader 
Service Number 30. 

— Richard Eckhouse, University of 
Massachusetts at Boston 


Power Pak 2.1. We have always 
praised Multisoft’s products. The lat¬ 
est release, Version 2.1, of Power Pak 
is no exception. It comes with a disk 
cache, a keyboard and screen acceler¬ 
ator, a print spooler, a RAM disk, and 
a memory-usage display. Although in¬ 
stallation is automatic, there are plen¬ 
ty of options for optimizing your envi¬ 
ronment. Also included — lest you 
not believe the performance gains — 
is a set of benchmark programs for 
disk testing. 

As before, the Power Pak manual is 
well-written and thorough. From the 
table of contents to the multiple ap¬ 
pendixes onto the index at the end, 
the manual serves as an example for 
correct manual writing. In addition, 
there is now a reference card that is 
brief but extremely helpful, especially 
if you are not one to read manuals. 

Many things have changed for the 
better since we last looked at Power 
Pak. In addition to better perfor¬ 
mance for Windows 3.0 users, the 
package lends memory to other appli¬ 
cations (whether Windows or DOS), 
and uses upper memory blocks and 
smaller memory footprints. The pack¬ 
age also reuses commands more easily 
in the keyboard and screen accelera¬ 
tors. 

At $129.95, Power Pak is an eco¬ 
nomical bundling of Windows and 
DOS utilities to improve PC perfor¬ 
mance. A lot of other vendors recog¬ 
nize this as well; you will find either 
Power Pak or Super PC-Kwik (the 
disk accelerator) bundled with their 
products. 

Readers can contact Multisoft 
Corp. at 15100 S.W. Koll Pkwy., Ste. 

L, Beaverton, OR 97006; (800) 234- 
5945; or circle Reader Service Num¬ 
ber 31. 

— Richard Eckhouse, University of 
Massachusetts at Boston 


Maxell floppies. In December 1989, 
I wrote a review note on a device that 
doubled the capacity of 3.5-inch disks 
by punching the missing square hole 
required for HD (high density) flop¬ 
pies. The DoubleDisk Converter im¬ 
pressed me favorably at the time. Re¬ 


cently, I received a “rebuttal” in the 
form of a press release from Maxell 
with the heading “Floppy Disk Pi¬ 
rates.” While that title may convey 
the wrong message, the contents of 
the press release were clear and worth 
summarizing. 

The essential point is that when you 
use such a product, you are fooling 
yourself into thinking that all floppies 
are created equal. There are differ¬ 
ences in the thickness of the coating 
(for instance, the coating on a double 
density, or DD, is nearly twice as 
thick as it is on an HD floppy). This 
disparity results in media over-satura¬ 
tion when you write to a converted 
HD floppy. Consequently, when you 
read the floppy, you may see shifted 
data bits that cause a higher error rate 
and data loss, particularly when the 
floppy is read on a different drive 
from the one it was written on. 

Readers of Computer are familiar 
with the grading of components, par¬ 
ticularly for ICs and computer chips. 
Floppies are also graded and are certi¬ 
fied to be error-free at a given bit 
density. Is it worth the savings to use 
a DD floppy in an HD environment? 
Because the price differential is so 
low, I now buy only HD floppies. To 
help me choose the “right” brand, 
Maxell sent me a box of them to try. 
I’ve long thought of Maxell as the pre¬ 
mium brand, based on my experience 
with its audiocassettes. That was still 
true after I tried the new “super RD” 
or MF2-HD floppies (the RD stands 
for reliable and durable). 

Among the differences between 
Maxell’s floppies and others is a new 
airtight dual interlocking flex shutter 
made out of plastic rather than metal. 
This flex shutter is supposed to adhere 
better to the shell and reduce the in¬ 
troduction of particles onto the floppy 
surface. The shell itself is more flexi¬ 
ble and provides better head contact. 
The magnetic media has been im¬ 
proved, and there is a new lubricant 
and binder to offer head protection. 

For those interested in really high 
density floppies, Maxell also offers a 
21-Mbyte 3.5-inch “floptical” that 
works with Insite Peripherals and Io¬ 
mega drives. Now what I’d like to 
have is one drive or floppy that allows 
me all that storage space yet main¬ 
tains compatibility with all my boxes 
of existing floppies! 

Readers can contact Maxell Corp. 
of America at 22-08 Rte. 208 South, 
Fair Lawn, NJ 07410; (201) 794-5900; 
or circle Reader Service Number 32. 

— Richard Eckhouse, University of 
Massachusetts at Boston 
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ASSESSMENT OF QUALITY SOFTWARE DEVELOPMENT TOOLS 


May 27 to 29,1992 

Weston Canal Place, New Orleans, Louisiana 

Preliminary Program 




Sponsored by: 

Tulane University 
In Cooperation with: 

IEEE Computer Society TCSE 
With Assistance: 

IBM Systems & Software Educ. 


Wednesday, May 27 

8:30-10:00 

Program Chair: Ez Nahouraii, IBM 

Local Host: Frederick Petry, Tulane University 

Keynote 

Richard B. Butler, Director - Enterprise Systems 
Systems and Programming, IBM Corporation 

10:30-12:00 

Testing Tools - part 1 

Chair: David Belanger, AT&T Bell Laboratories 

AT AC: A Data Flow Coverage Testing Tool for C* 

J.R. Horgan, S.A. London, Bellcore 

SEMST: Support Environment for Management of Softw. Testing 
LuLu Liu, Polytechnic of Central London (UK) 

Dave Robson, University of Durham (UK) 

A Linear Combination Software Reliability Modeling Tool with 
a Graphically-Oriented User Interface 

Allen P. Nikora, T.M. Antczak, Jet Propulsion Laboratory 
Michael R. Lyu, University of Iowa 

12:00 - Tools Exhibits begin (Wednesday afternoon & Thursday) 

1:30-3:00 

Evaluating Tools 

Chair: Leonard Tripp, Boeing Computer Services 

Softw. Design Tools Evaluation in Context of a Metaparadigm 
Peter Kokol, University Maribor (Slovenia) 

A Systematic Approach to CASE Selection 

Kurt Schneider, University of Stuttgart (Germany) 

Evaluating Software Testing Tools 

Robert M. Poston, Michael P. Sexton, Programming Environments 

3:30 - 5:00 

Standards for Tools Interconnection 

Chair: Robert M. Poston, Programming Environments 

Introducing IEEE-CS 1175: A Standard for Tool Interconnections 

Peter Eirich, IEEE-CS Task Force on Professional Computing Tools 

Introducing CDIF 
Introducing PCTE 

Thursday, May 28 

8:30 -10:00 

Program Understanding 

Chair: Elliot Chikofsky, Northeastern University 

Assessment of Support for Program Understanding 
Eun Man Choi, Illinois Institute of Technology 
Anneliese von Mayrhauser, Colorado State University 
Automated Assessment of Program and System Quality 

Sukesh Patel, Rich Baxter, William Chu, Brian Sayrs, Steve Sherman, 
Lockheed Software Technology Center 
Assessment of Reverse Eng. Tools: A MECCA Approach 

Torbjorn Skramstad, Md. Khaled Khan, Univ. of Trondheim (Norway) 

10:30 - 12:00 

Testing Tools - part 2 

Chair: Charles Richter, MCC 

Experience in Using Three Testing Tools for Research and 
Education in Software Engineering 

Joseph R. Horgan, Bell Communication Research 
Aditya P. Mathur, Purdue University SERC 

A Tool for Software Quality 

C. Lac, J.-L. Raffy, Institut National des Telecommunications (France) 

An Intelligent Approach to Verification and Testing of the 
Configurator 

Pei-Lei Tu, Jen-Yao Chung, IBM T.J. Watson Research Center 


Thursday, May 28 

1:30-3:00 (parallel sessions) 

Layout and Presentation of Graphs - part 1 

Chair: Elliot Chikofsky, Progress Software 

An Object Oriented Layout for Directed Graphs 
Patrick Brown, T.Gargiulo, IBM Sterling Forest 
A-Vu: A Visualization Tool for Software Systems 

J.C. Smart, R. Vemuri, Lawrence Livermore National laboratory 

Software Process and Quality 

Chair: John Cameron, LBMS UK 

Open Process/6000: A Total Solution for Process Management 
Germain Sagols, IBM AIX CASE European Center (France) 
SQEngineer: A Methodology and Tool for Specifying and 
Engineering Software Quality 

Magdy Hanna, William Loew-Blosser, University of St. Thomas 
REQUEST: A Market-Driven Requirements Management Process 
Albert C. Yeh, IBM 

3:30 - 5:00 (parallel sessions) 

Layout and Presentation of Graphs - part 2 

Chair: Elliot Chikofsky, Progress Software 

Graph Visualization in Software Analysis 

Emden R. Gansner, Eleftherios Koutsofios, Stephen C. North, 
Kiem-Phong Vo, AT&T Bell Laboratories 
Graph Services for Program Understanding Tools 
Patrick Brown, David W. Stafford, IBM Sterling Forest 

Design: Methods and Tools 

Chair: Dilip Soni, Siemens Corporate Research Inc. 

Using the ECMA Ref Model for CASE Environment Frameworks 
in the Development of Workbench for KBS Development 

Yaron Shavit, Cap Gemini Innovation (France) 

Architecture Flow Diagrams Under Teamwork 
Tom Nicinski, Fermi National Accelerator Laboratory 
Integrated CASE: Our Experience with Teamwork and Rational 

Peter H. Luckey, Robert M. Pittman, Richard D. Saxton, 

IBM Federal Sector Division 

Friday, May 29 

8:30 -10:00 

Testing Tools - part 3 

Chair: Claire Lamy, IBM France 

Design, Implementation, and Case Study of a Function Level 
Unit Test Environment 

Christopher J. Born, Jim D. Creasman, IBM Network Systems Divi. 

PIE-Cs: A Tool for Predicting Software Testability 

Jeffrey M. Voas, Keith W.Miller, NASA Langley Research Center 
Jeffery E. Payne, BDM International 

CDA: A System for Understanding the Dynamic Properties of 
Data Processing Programs 

William E. Howden, Guangming Shi, Univ. of California at San Diego 
10:30 -12:00 

Program Chair: Ez Nahouraii, IBM 

Panel: Strategic Direction in Quality Softw. Development Tools 


Hotel Information: 

Weston Canal Place - (504) 566-7006, (800) 228-3000 

ask for "Software Tools" - $80 single, $90 double; govt: $73/$83 

Rates apply for 3 days before and after. Reserve by May 4, 1992. 


For more information, contact: 
Judy Lee (407) 982-1048 


Advance (received by May 8): IEEE/CS members $200, Others $250, Full-time students $50; Late (after May 8): $250 / $300 / $50. 

Mail check payable to "IEEE Tools Symposium” to: IBM - Zip 1018, Attn: Judy Lee, 1000 NW 51st Street, Boca Raton, Florida 33431 USA 














NEW PRODUCTS 


When you can take it with you 


Compaq brings out four more models 


Compaq has announced two note¬ 
books and two portables. 

The LTE Lite/20 and Lite/25 note¬ 
books use Intel’s 20- and 25-MHz 
386SL microprocessors and incorpo¬ 
rate power-management features to 
give users up to 4.5 hours of battery 
operating time in a 6-pound com¬ 
puter. 

The LTE Lite/20 serves users run¬ 
ning basic spreadsheet, windowed, 
and e-mail applications. It has 2 
Mbytes of RAM and is available with 
up to 84 Mbytes of fixed-disk storage 
space. The Lite/25 targets users run¬ 
ning advanced productivity business 
and windows applications, including 
financial analysis, software develop¬ 
ment, and graphics. The Lite/25 has 
16 Kbytes of high-speed cache memo¬ 
ry, 4 Mbytes of system memory, and 
up to 120 Mbytes of fixed-disk storage 
capacity. 

Both models measure 8.5 x 11 x 
1.75 inches and feature the Compaq 


Toshiba America Information Sys¬ 
tems has introduced a 12-lb. 486 col¬ 
or portable that fits into a briefcase. 

The T6400 features Intel’s 486DX 
or 486SX microprocessor, a 120- or 
200-Mbyte hard-disk drive, two cred¬ 
it-card memory slots, a full-length 
IBM-compatible 16-bit expansion 
slot, an internal dedicated modem 
slot, and a 101-key detachable key¬ 
board. 

A 10.4-inch-diagonal 640 x 480-pix¬ 
el display comes with a 16-shade gray¬ 
scale VGA gas-plasma screen or a 


Smart Power Pack, an intelligent bat¬ 
tery pack with a built-in microproces¬ 
sor that automatically monitors sys¬ 
tem power use. Additionally, the 
company’s Maxlight VGA display 
uses a patented backlighting system 
that improves screen quality while it 
reduces power requirements by half 
over earlier displays, according to the 
company. 

Options for the LTE notebooks in¬ 
clude a full-function desktop expan¬ 
sion base that lets users quickly con¬ 
vert a notebook to a desktop PC, and 
an enhanced 9,600-bps internal data 
modem. 

Costs range from $2,899 for a Mod¬ 
el 40 Lite/20 to $4,699 for Model 120 
Lite/25. The desktop expansion base 
is $929, and the 9,600-bps modem is 
$599. 

Compaq has also introduced the 
Portable 486c, an EISA-based AC- 
powered transportable that com¬ 
bines the Intel 33-MHz 486 micro- 


256-color Super VGA thin-film tran¬ 
sistor active-matrix LCD. TFT tech¬ 
nology uses an individual driver for 
each pixel with all drive transistors 
fabricated on the glass. 

Costs range from $5,699 for the 
T6400SX (with a 25-MHz 486SX mi¬ 
croprocessor, 120-Mbyte disk, and gas 
plasma screen) to $9,749 for the 
T6400DXC (with a 33-MHz 486DX 
microprocessor, 200-Mbyte disk, and 
TFT color monitor). 

Reader Service Number 35 


processor with a thin-film transistor 
(TFT) active-matrix VGA color dis¬ 
play. 

The Portable 486c comes in two 
models: Model 120 with a 120-Mbyte 
fixed-disk drive, and Model 210 with a 
210-Mbyte drive. Both models have 4 
Mbytes of system memory, a 3.5-inch 
1.44-Mbyte disk drive, and a full-size 
detachable keybord. 

Model 120 costs $9,999, and Model 
210 is priced at $10,999. 

Reader Service Number 36 


AST adds notebook 

AST Research has added the 25- 
MHz NB-SX25 to its Advantage se¬ 
ries. The notebook weighs 7.3 pounds 
and includes a 60-Mbyte hard-disk 
drive, a 1.44-Mbyte 3.5-inch disk 
drive, a 2,400-baud internal data mo¬ 
dem, and 4 Mbytes of RAM, expand¬ 
able to 8 Mbytes. It also comes with 
serial and parallel ports, an external 
monitor, a numeric keypad/mouse 
port, and a fast-charge AC adapter. 

An 8.5-inch-diagonal VGA display 
with a film supertwist LCD flat panel 
produces a paper-white screen. 

The NB-SX25 comes with MS-DOS 
5.0 installed and includes Prodigy on¬ 
line information service software, 
MTEZ data communications soft¬ 
ware, and Borland’s Sidekick desktop 
organizer. A NiCad battery pack pro¬ 
vides three hours of battery life. 

Retail outlets establish pricing for 
the Advantage products. 

Reader Service Number 37 


Toshiba comes with 486 and color too 
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Dell comes in color 


The Dell System 325NC color 
notebook, based on an Intel 25-MHz 
386SL microprocessor, uses a pas¬ 
sive-matrix color LCD that can si¬ 
multaneously display 16 colors in a 
9.25-inch-diagonal viewing area. 
Resolution reaches 640 x 480 (VGA) 
and 320 x 200 with 256 colors, both 
from a palette of 262,144 colors. The 
system includes 4 Mbytes of RAM, 
64 Kbytes of four-way set-associa¬ 
tive cache memory, and a 3.5-inch 
1.44-Mbyte internal disk drive. 

Nickel-metal hydride batteries of¬ 
fer up to three hours of operating 
power under normal use. Enhanced 
Parallel Port technology emulates a 
traditional bus to increase parallel- 
port performance by a factor of up 
to 30 times, according to the compa¬ 
ny. 

Each 325NC ships with version 8.1 
of the Microsoft Mouse software, 
which incorporates LCD screen en¬ 
hancements. The computer is priced 
at $3,999 for the 60-Mbyte hard 
drive model, and $4,299 for the 80- 
Mbyte model. 
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The 6.9-pound Dell 325NC color notebook can be expanded to hold 12 Mbytes 
of RAM. 


Research and information tools 


Bowker offers books on ROM 


R.R. Bowker’s Library Reference 
Plus provides six databases on one 
CD-ROM: “American Library Direc¬ 
tory”; “American Book Trade Direc¬ 
tory”; “Publishers, Distributors, and 
Wholesalers of the United States”; 
“The Bowker Annual Library and 
Book Trade Almanac”; “Literary 
Market Place”; and “International 
Literary Market Place.” 


Users can employ fielded and full- 
text searching in 69 categories. Bool¬ 
ean search options include name of in¬ 
stitution; names of personnel; major 
classification; city, state, country, and 
zip; area code; ISBN prefix; expendi¬ 
tures for books; periodicals and docu¬ 
ment preservation; salaries, audiovisu¬ 
al holdings; population served; book 
trade conferences and meetings; and 


keywords. Categories include infor¬ 
mation on 21,000 software producers 
and manufacturers. 

Users can save queries and restore 
them to the workspace, append notes 
to full citations, and generate mailing 
lists and labels. 

A one-year subscription costs $695. 
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Hypertext dictionary provides statistics terms 


Idea Works Inc. has announced 
Hyper-Stat Version 1.0, a memory- 
resident hypertext dictionary of statis¬ 
tical, methodological, and graphical 
terms. 

The software contains 1,900 terms 
and 4,000 hypertext links for further 
information and clarification. Users 


can access terms by selecting from a 
scrolling list, typing them, or selecting 
highlighted hypertext terms. The MS- 
Windows version runs simultaneously 
with spreadsheets, databases, graph¬ 
ics, or statistics programs. 

System requirements for Hyper-Stat 
DOS include MS-DOS 2.0,1 Mbyte of 


hard-disk space, and a mouse. The 
Hyper-Stat Windows version requires 
MS-Windows 3.0 running in standard 
or enhanced mode, 1 Mbyte of hard¬ 
disk space, and a mouse. Either ver¬ 
sion is $99. 
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Abstracts on CD-ROM now an option 


Keeping up on patents 

MicroPatent’s Who Invented What? 
contains full-text abstracts of patents 
issued during 1990-1991 on CD-ROM. 
Users can search these patents by key¬ 
word, inventor, patent holder, status, 
patent number, issue date, application 
number, application date, US refer¬ 
ences, US classification, international 
classification, and residence of first in¬ 
ventor — or any combination of the 
above. 

Minimum hardware configuration is 
an XT computer with 640 Kbytes of 
RAM, 3 Mbytes of available hard-disk 
space, and an ISO 9660-compatible 
CD-ROM drive. The disk and applica¬ 
tions software cost $199. 

MicroPatent’s monthly automated 
patent-searching CD-ROM provides 
abstracts for $1,100 per year. A fully 
searchable text of issued patents is 
available for $1,450 per year. A week¬ 
ly $5,500 series contains facsimile cop¬ 
ies of patents with drawings that can 
be viewed or printed on any PC and 
laser printer. 
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Interactive music lessons 

Warner New Media’s The Orchestra 
lets users see orchestral instruments, 
hear how they sound, and learn how 
they are played. 

Graphics highlight which instru¬ 
ment is playing, and an illustrated 
analysis explains how pieces are put 
together. Features include a conduct¬ 
ing lesson, a composing lesson in 
which the user selects the instruments 
to play and hears the result, and an ar¬ 
cade in which the user plays such 
games as Name that Instrument and 
Music Trivia. Display features include 
a full-color background and multiple 
windows. 

A time line teaches music history 
with audio examples that range from 
Gregorian chants to jazz improvisa¬ 
tion. Other features include 500 extra 
audio examples, a music guide, pro- 
nouncer and sound indexes, biograph¬ 
ical information, and a glossary. 

Users need an Apple Macintosh 
running System 6.0.5 or later with at 
least 2 Mbytes of memory, a hard disk 
with at least 4.5 Mbytes of free space, 
a CD-ROM drive, audio-playback 
equipment, and HyperCard 2.0. 

The CD-ROM disk costs $79.98. 
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The Institute for Scientific Informa¬ 
tion is releasing a new version of its 
Science Citation Index Compact Disc 
Edition (SCI CDE). In addition to the 
regular bibliographic information, the 
reference product offers English-lan¬ 
guage author abstracts for 83 percent 
of the article information. SCI CDE, 
which provides access to 3,100 interna¬ 
tional journals in science and technolo¬ 
gy, is also available without abstracts. 

The abstracts version features refer¬ 
ence searching that lets researchers 
find recent articles that cite a known 
relevant work. Indexing links all arti¬ 
cles that have one or more references 


Build your own nucleus with 

Version 3.0 of FCC Nuclear Struc¬ 
ture Software for IBM PCs explains 
the basics of nuclear structure theory 
with graphics. A fully interactive mod¬ 
eling capability lets users build and 
modify specific nuclei by using a menu 
and a mouse. 

Users construct nuclei in 3D space 
by using a default build-up sequence 
and specifying the numbers of protons 
and neutrons, or by building them 
with nucleons and quantum subshells. 
The position of valence nucleons can 
then be altered to test the spin, parity, 
binding energy, radius, coulomb ener¬ 
gy, and magnetic and quadrupole mo¬ 
ments of various configurations. Ex- 


Parallel Unix on 88100s 

Novadyne Computer Systems’ XT 
series of multiprocessor systems are 
powered by two or four 33-MIPS 
88100 RISCs and run on a modified 
version of Unix System V that sup¬ 
ports parallel processing through mul¬ 
tithreading operations. The Reality 
operating system functions as a rela¬ 
tional database management system 
under Unix and provides disaster- 
recovery capabilities. 

The XT architecture contains a 100- 
Mbyte/s Mbus used exclusively for in¬ 


in common. Author keywords and a 
function called Keywords Plus let us¬ 
ers retrieve additional information. 

Users will need an IBM PC or true 
compatible with 640 Kbytes of RAM 
(with 416 Kbytes free), MS-DOS 3.1 
or higher, and a drive with MS-DOS 
CD-ROM extension 2.0. A Macintosh 
version will be available in the third 
quarter of 1992. 

Current users can add the 1992 ab¬ 
stract version for $3,833. The full 
package costs $14,783 for the 1992 
edition. 

Reader Service Number 43 


a mouse 

perimental data for 1,000 isotopes 
comes on disk for comparison with 
model predictions. 

Numerical comparisons made among 
the shell, liquid drop, and FCC models 
of nuclear structure are graphically dis¬ 
played. Users can change the color 
coding of nucleons to emphasize quan¬ 
tum values. 

The software from TransTech AG, 
Switzerland, runs on IBM PC XT/AT/ 
PS2s and compatibles with EGA or 
VGA capabilities. A hard disk, math 
coprocessor, and Microsoft mouse are 
recommended but not required. 
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ternal traffic between processors and 
memory. The architecture also in¬ 
cludes a standard VMEbus for com¬ 
munications, single or dual SCSI bus¬ 
es for mass storage, and an Ethernet 
channel for terminal connectivity. The 
design minimizes contention between 
high- and low-speed signals and fea¬ 
tures symmetrical as well as parallel 
processing. 

The XT series starts at $70,000. 
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Workstations, workstations, workstations 



CISC gives more bang for your bucks 


Fox Computers has announced a 32- 
bit 486 CISC with a reported 0.3-ms- 
average hard-disk access time and a 
12-Mbyte/s data-throughput rate. 
MicroFrame is optimized for Windows 
3.0 and comes with MS-DOS in an in¬ 
dustrial full-tower configuration. 

Standard features include 32 Mbytes 
of 70-ns zero-wait-state system memo¬ 
ry, 256 Kbytes of 20-ns external DMA 
cache, and a 32-bit SCSI II host I/O 
adapter with 4 Mbytes of hardware 
cache. The system also boasts a 1.2- 
Gbyte SCSI II hard drive, a 680-Mbyte 
internal CD-ROM drive, a 240-Mbyte 
internal tape backup system, and both 
3.5- and 5.25-inch floppy drives. 


System/6000 series expanded 

IBM has added three desktop and 
two deskside models to its RISC 
System/6000 series of workstations. 

The 33-MHz Powerstation/Pow- 
erserver 220 features Ethernet and 
SCSI capabilities and offers mono¬ 
chrome, gray-scale, or color support. 
Reputed performance reaches 25.9 
SPECmarks and 6.5 Mflops. 

Powerstations/Powerservers 340 
and 350 also feature Ethernet and 
SCSI capabilities. The 33-MHz 340 
runs at 56.6 SPECmarks and 14.8 
Mflops. The 350, at 42 MHz, delivers 
71.4 SPECmarks and 18.6 Mflops. 

The deskside Powerstation/Pow- 
erserver 520H has a 25-MHz proces- 


Silicon Irises bloom again 

Silicon Graphics has introduced a 
new series of single-user deskside 
systems called Iris Crimson. Binary 
compatible with the Iris 4D worksta¬ 
tions and servers, the seven new 
models incorporate a 50-MHz 64-bit 
Mips R4000SC that reputedly deliv¬ 
ers 70-SPECmarks performance. The 
R4000SC supports a large secondary 
cache and has a 100-MHz internal 
clock rate achieved by breaking each 
instruction into tasks that can be han¬ 
dled in one clock cycle. ASICs (appli¬ 
cation-specific integrated circuits) 
provide memory-transfer rates of 400 
Mbytes/s. 


The Super VGA color monitor 
with 0.26-mm dot pitch is digitally 
controlled and offers automatic siz¬ 
ing and a 1,280 x 1,024 noninterlaced 
resolution. 

The system also works in Unix, 
Xenix, and OS/2 environments and 
runs recompiled IBM System 34/46/ 
38 and AS/400 programs written in 
RPG. Up to four CPUs can be added 
to support parallel processing and 
multitasking. System memory is ex¬ 
pandable to 64 Mbytes, and the hard¬ 
disk storage to 14 Gbytes. 

MicroFrame costs $13,995. 
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sor and ratings of 43.5 SPECmarks 
and 11.5 Mflops. The deskside 560 
contains the 50-MHz IBM RISC pro¬ 
cessor, which supports 89.3 SPEC¬ 
marks and 30.5 Mflops. 

The workstations come with AIX/ 
6000 Version 3.2, which fully complies 
with the Open Software Foundation’s 
Application Environment Specifica¬ 
tion. A suite of CASE tools and Net¬ 
Ware for AIX/6000 from IBM Ver¬ 
sion 3.11 are also offered. 

The systems range from under 
$7,000 to around $64,000. 
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Configurations include the Crim¬ 
son/5, a CPU without graphics that 
can serve as a computational or file 
server; and the Entry, which features 
graphics with an 8-bit-plane sub¬ 
system and dithering to produce 24- 
bit color. The X5 model also includes 
a geometry engine processor for poly¬ 
gon performance and solids modeling 
for computationally intensive applica¬ 
tions. The XS24 adds 24-bit-plane col¬ 
or. The Elan model includes XS24 
features, a hardware Z-buffer, and 
four geometry engine processors. 

The Crimson/VGX provides Pow- 
erVision graphics, fast polygon perfor¬ 


HP addresses the low end 

Hewlett-Packard has added two 
entry-level workstations to its Apol¬ 
lo 9000 Series 700. 

Model 705 uses a 35-MHz PA 
(Precision Architecture) RISC to 
deliver 35 MIPS, 34 SPECmarks, 
and 8 double-precision Mflops per¬ 
formance, according to the company. 
The 705 also provides XI1 window¬ 
ing performance, 8 Mbytes of RAM, 
and a 19-inch gray-scale monitor 
with 1,280 x 1,024 resolution. 

Model 710 with a 50-MHz proces¬ 
sor offers 57 MIPS, nearly 50 SPEC¬ 
marks, and 12.2 double-precision 
Mflops performance. Graphics op¬ 
tions include a 19-inch, 8-bit gray¬ 
scale 1,280 x 1,024 monitor; a 16- 
inch, 8-bit color 1,024 x 768 monitor; 
and a 19-inch, 8-bit color 1,280 x 
1,024 monitor. The 710 comes with 
16 Mbytes of ECC RAM. 

Both workstations incorporate a 
320-Kbyte instruction cache and a 
64-Kbyte data cache and support up 
to 64 Mbytes of ECC RAM, 840 
Mbytes of internal storage, and 9.4 
Gbytes of total disk capacity. Inter¬ 
nal removable media include a CD- 
ROM drive, a 3.5-inch floppy disk 
drive, and a 2-Gbyte 3.5-inch DDS 
tape drive. The platforms run the 
HP-UX 8.07 operating system and 
support multimedia capabilities. 

Model 705 costs $4,990; the 710 
lists for under $10,000. Monitors for 
the 710 range from $9,490 to 
$13,990. 
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mance, and hardware-assisted antialias¬ 
ing and texture-mapping capabilities. 

The systems include up to 256 
Mbytes of memory, 3.6 Gbytes of in¬ 
ternal disk storage, two SCSI channels, 
and four VME slots. They come with 
the IRIX operating system, the Work¬ 
space visual interface, the Explorer 
data-visualization package, and the 
Showcase tool for presentations. 

Models start at $27,900 with a con¬ 
figuration of 16 Mbytes of memory. 
Board exchanges allow upgrading 
throughout the series. 
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1C Announcements 
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Actel 

A1240, A1240-1 
FPGAs 


Analog Devices 
OP-282, OP-482 
Op amps 


Hitachi America 
H8/500 series 
Microcontrollers 


Motorola 

MC68F333 

Microcontroller 


Nat’l Semiconductor 
DP8025 

Interface controller 


NMB Technologies 
A A A4M200 family 
CMOS DRAMs 


Oak Technology 
OTI-020, OTI-040 
386 chip sets 


Oak Technology 
OTI-087 

Graphics controller 


Racal-Dana 
7251 series 

VXIbus downconverter 


Raytheon 
RLDA80 
Macrocell array 


Texas Instruments 
SN65LBC176, 
SN75LBC176 
Transceivers 


Field-programmable gate arrays with 4,000 gates include two logic module types, two clock 
distribution networks, and advanced routing algorithms and resources. The A1240-1 is the 
speed version; it achieves up to 66-MHz overall system performance. Available in 132-pin 
ceramic PGAs and 144-pin PQFPs. Cost (in 100s): from $150 (A1240); from $180 (A1240-1). 

Dual OP-282 and quad OP-482 are low-power, 4-MHz unity gain-bandwidth operational 
amplifiers. Drawing 250 pA maximum supply current, slew rate/amplifier exceeds 7V/ps 
with settling time of 1.6 ps to 0.01 %. Offset voltage is 3 mV for OP-282, 4 mV for OP-482. 
Both come in various packages. Cost (1,000s, PDIPs): $1.05 (OP-282); $1.72 (OP-482). 

An 8/16-bit architecture provides 16-bit processing in 8-bit package. Features include 16- 
Mbyte address space, orthogonal instruction set, extended 32-bit math operations, and in¬ 
tegrated on-chip peripherals, including data transfer controller and 10-bit A/D converter. 
Minimum instruction cycle time is 200 ns and clock rate is 10 MHz. Cost: from $11.85 (H8/ 
500 in 5,000-piece lots) to $34.10 (H8/536 in 1,000-piece lots). 

This 32-bit microcontroller integrates 64 Kbytes of nonvolatile flash EEPROM on a single 
chip along with peripherals such as the CPU32 from the M68000 family, a queued serial 
module, and a single-chip integration module. Otherfeatures include 512 bytes of standby 
RAM, 3.5 Kbytes of general standby RAM, 8-channel 10-bit A/D converter, and intelligent 
16-bit timer. Sample quantities available in 160-pin PQFP. Cost: $199.95. 

Token-Ring Protocol Interface Controller (TROPIC) is a microCMOS VLSI device for im¬ 
plementing IEEE 802.5 Token-Ring LAN interface adapters. The chip includes analog and 
digital token-ring interfaces and bus interface support for IS A, MCA, and 68xxx hosts. Sam¬ 
ple quantities available in 175-pin flipchip C4 PGA. Cost (in 100s):$129. 

These 4-Mbit, 40-ns DRAMs support direct zero-wait-state access with up to 25-MHz mi¬ 
croprocessors. R AS access times are 40,45,50,60, and 80 ns, with read/write cycle times as 
fast as 80 ns. Optional battery backup. Available in 1-Mbit x 4 and 4-Mbit x 1 versions in 
various packages. Cost (in 10,000s): from $20 for 40-ns versions; $16 for 80-ns versions. 

Chip sets designed for microprocessors running at up to 40 MHz. OTI-020 set contains 70% 
of a 386 desktop PC’s circuitry; OTI-040 set contains 80% of a 386 notebook’s circuitry. 
Functions include system clock, DMA and ISA bus controllers, and support for local bus 
VGA graphics. Cost (in 1,000s): $21 for OTI-020; $40 for OTI-040. 

Super VG A graphics chip attaches directly to 386 or 486 microprocessors via high-speed 32- 
bit local bus rather than routing commands through the AT or ISA bus connections. OTI-087 
adheres to the Super VG A standards, but includes 24-bit color technology for expansion into 
true-color PC world. Samples available in 160-pin PQFP. Cost (in 1,000s): $31. 

Single-slot, C-size models convert signals with UHF to microwave frequencies to interme¬ 
diate frequencies below 500 MHz. Detected output can be used for pulse analysis with a 
waveform analyzer. Optional input isolation and gain conversion for IF and RF amplifica¬ 
tion on all models. Racal-Dana will customize models for specific applications. Cost: $4,995. 

Mixed-signal ASIC consists of analog and digital macrocells and other auxilliary compo¬ 
nents, such as transistors and thin-film resistors. Architecture integrates both bipolar analog 
and medium-speed digital functions and uses a 32 V process that supports industrial and con¬ 
trol applications. Nonrecurring engineering charges — including layout, 10 prototypes, and 
test development — start at $30,000. Minimum order size is $100,000. 

Monolithic integrated circuits are designed for bidirectional data communication on multi¬ 
point bus transmission lines. They meet the RS-485 standard but consume less than 6 mA/ 
channel of power supply current. SN65LBC176 is characterized for operation from -40°C to 
85°C; SN75LBC176, from 0°C to 86°C. Cost (in 1,000s): $1.57 for SN75LBC176. 


Texas Instruments Data acquisition converter uses 10-bit, switched-capacitor, successive approximation net- 
TC1550IFN work and requires only one read instruction for conversions. High-speed three-state parallel 

A/D converter port interfaces directly to a DSP or microprocessor system database. Cost (in 1,000s): $6.27. 
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• Discounts of up to 50% on Computer Society Press 
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visualization 
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Microsystem Announcements 

Company, Model, Function_ Comments r,S, No. 


American Eltec 
IC40 

Imaging computer 


Arcom Control Systems 
SCIM386SXplus 
STEbus processor board 


Belkin Components 
LaserlinklllSi 
Printer-sharing boards 


DynaFive 

Baby Bullet 386SX 

Single-board computer 


Heurikon 

HK68/VSIO 

Serial interface board 


John Fluke Mfg. 
9110FT 

Trouble-shooting tool 


Proxim 
RangeLAN 
Wireless LAN adapter 


Radstone Technology 
VMEARINC 429/575 
Intelligent/interface 
controller 

Real Time Devices 
VF900 

A/D converter 


USATeknik 
7200IPV series 
Dual-profile CPU 


WinSystems 
CX series 
Card cages 


Xycom 
XVME-630 
VMEbus processor 
module 


Built-in capability for digital imaging and graphics display. Frame grabber digitizes com¬ 
posite video inputs from up to four standard video cameras and displays images on work- 
station-quality monitors without interlace flicker. Programmable monitor resolution up 
to 1,280 x 1,124 pixels at 60 Hz, noninterlaced. On-board 68040 CPU has 25-MHz clock 
and throughput of 20 MIPS and 3.5 Mflops. Cost: $5,100. 

Complete PC AT-compatibility provided by Chips and Technologies’ SCATSX chip set 
on a 100 x 160-mm single-Eurocard module. Features 1 Mbyte of RAM and extensible 
I/O capability; interfaces to both STEbus and local expansion bus. On-board memory lets 
users run Unix. Cost: £627 (100s); £207 (Super VGA module add-on). 

Three boards for installation in the LaserJet IHSi printer optional I/O port let up to 15 us¬ 
ers send jobs to the printer simultaneously; queues jobs in buffers and sends data to Laser¬ 
Jet on a FIFO basis. Lets users work on other tasks to avoid waiting for printer. Boards 
come with 1 Mbyte of memory, upgradable to 4 Mbytes. Cost: $795-$l ,295. 

SBC operates at 25-MHz. Solid-state disk uses nonvolatile SRAM, EPROM, or EEPROM 
to emulate disk drives in harsh environments or where high reliability is required. Includes 
two serial ports, 16 Mbytes of plug-in memory, SCSI and coprocessor-chip sockets, one par¬ 
allel port, IDE hard-disk controller, and watchdog timer. 

68030-based VMEbus serial board features 18 RS-232C serial I/O ports, up to 4 Mbytes of 
DRAM, VMEbus master/slave interface, and 32-MHz 68EC030 controller. Plug-over 
module connectors for custom I/O interfaces and three programmable 16-bit counter/ 
timer channels are also included. Cost: $2,195. 

Incorporates functional test and stimulus routines and a single-point probe for tracking 
down faulty components in digital circuitry of 8-, 16-, and 32-bit microprocessor-based 
boards. Includes Fluke’s Spectrum Windows 3.0 interface. Cost: $13,000 (not including an 
IBM-compatible PC and IEEE interface card). 

ISA interface card for desktop and portable PCs fits into a full-length slot and includes a 
small antenna that extends from the PC backplane. Provides driver support for NetWare 
2.X, NetBIOS, and Artisoft’s LANtastic networks. Uses spread spectrum radio frequency 
technology; no FCC licensing needed. Range up to 800 feet. Three full channels. Cost: $495. 

Full Mil-Spec ARINC-1 features eight receive and four transmit channels, and can handle 
all 12 simultaneously. Supports word or string data moves. All channels programmable for 
12.5- and 100-Kbps operation. Low-level communications protocols handled by 16.7-MHz 
68020 CPU. Up to 64 Kbytes of zero-wait-state dual-ported SRAM available. Cost: $6,720. 

Variable resolution A/D converter for the PC/XT/AT bus. Uses V/F conversion to digitize 
analog signal in resolutions from 10 to 18 bits, at which point the VF900 can discern signals 
as low as 10 p. V. Features four differential analog input channels, programmable gain, 
selectable input voltage ranges, 16 digital I/O lines, and 12-bit analog output. Cost: $495. 

IBM AT-compatible microcomputer for desktop, embedded, and passive backplane prod¬ 
ucts based on one PCB. Uses WD 7600 LSI chip set. Despite its small size, 80286-based 
7200 IPV includes 80287 coprocessor option, IDE drive controller to interface with hard¬ 
disk, floppy controller, and high-resolution Super VGA graphics controller. 

STDbus card racks and backplanes are based on 0.625-inch centers and have vertical card. 
Card cages with backplanes and backplanes only are offered with 3 to 26 slots in 3-slot 
increments. Output supplies of 50 W, 70W, and 100W available. Rack, table, and wall-mount 
configurations. Cost: from $100 (3-slot, wall-mount) to $450 (26-slot, 19-inch, rack mount). 

6U single-board processor incorporates 25- or 40-MHz 68EC030, with internal 256-byte 
instruction and data caches. Can use zero-wait-state local SRAM and contains three mem¬ 
ory banks, each with four 32-pin sockets. Bank one accepts high-speed SRAM, while bank 
2 accepts EPROM, and bank 3 is dual-ported to the VMEbus and can accommodate SRAM, 
EPROM, or Flash memory. Cost: from $1,950. 
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CALL FOR PAPERS 



IEEE Workshop on 
Applications of Computer Vision 


9 IEEE COMPUTER SOCIETY 


November 30 - December 2,1992 
Palm Springs, California 


General Chairman: 

Bir Bhanu 

Univ. of Calif., Riverside 


We would like to invite computer vision researchers and practitioners to participate in 
the IEEE Workshop on Applications of Computer Vision to be held in Palm Springs, 
California, November 30 - December 2,1992. 


Program Co-Chairmen: 

Charles Dyer 
University of Wisconsin 

Martin Herman 

National Inst, of Standards and Tech. 
Program Committee: 

Minoru Asada, Osaka University 
Matthew Barth, UC Riverside 
Bruce Batchelor, Univ. of Wales 
Rudd Bolle, IBM 

Peter Burt, David Sarnoff Rsch. Center 
Ernst Dickmanns, Univ. d. Bundeswehr 
Ed Delp, Purdue University 
Masakazu Ejiri, Hitachi Inc. 

Olivier Faugeras, INRIA 

Oscar Firschein, DARPA 

Bruce Flinchbaugh, Texas Instruments 

Herb Freeman, Rutgers University 

Kicha Ganapathy, AT&T 

Don, Gerson, ORD 

Allen Hanson, Univ. of Massachusetts 
Rick Holben, Odetics Inc. 

Katsushi Ikeuchi, Carnegie Mellon U. 
Ramish Jain, Univ. of Michigan 
Martin Levine, McGill University 
Joe Mundy, General Electric 
Ram Nevatia, Univ. of South. Calif. 
Andre Oosterlinck, Cath. Univ. Leuven 
Azriel Rosenfeld, Univ. of Maryland 
Jorge Sanz, IBM 
Banavar Sridhar, NASA 
Sargur Srihari, SUNY Buffalo 
Tom Strat, SRI 

Chuck Thorpe, Carnegie Mellon Univ. 


The goal of this workshop is to bring together an international forum of academic, 
industrial, and government researchers in order to present and discuss various 
applications of computer vision. This will allow researchers in the different 
application areas to interact and interchange ideas, so that applications are thoroughly 
understood and there is a transfer of concepts from one application area to another. 

The program will consist of high quality contributed papers covering computer vision 
applications that include, but are not limited to, photo-interpretation, navigation, 
manipulation, target recognition, cartography, manufacturing, inspection and quality 
control, medical analysis, document analysis, and space operations. Emphasis should 
be on novel research aspects and/or extensive experimental analysis for a given 
application domain; purely applying standard techniques to a new application problem 
using a few test images is not sufficient. 

SUBMISSIONS: Four (4) copies of papers should be submitted in English to the 
address below by June 1,1992: 

Martin Herman, Sensory Intelligence Group, National Institute of Standards and 
Technology, Bldg. 220, Rm. B124, Gaithersburg, MD 20899 USA 

Papers should be limited to 30 double-spaced pages, including figures, using no 
smaller than a 12 point font. Papers should include a title page containing the names 
and addresses of the authors, and an abstract of up to 200 words. Please also include a 
second title page with the abstract but without the names and addresses of the authors. 

Include a summary page — no more than one page containing answers to the 
following questions (answer each question separately and in order; please number your 
answers): 

1) What is the application area of the work reported in this paper? 

2) What is the paper about? 

3) What is the significance or original contribution of this work? 

4) How does your work relate to work by others? 

5) How can your work be applied or used by others? 

FURTHER INFORMATION: For further information or a copy of the advance 
program when available, write to either: 

Bir Bhanu, College of Engineering, University of California, Riverside, CA 92521, 


Financial Chain 
Subhodev Das 

Univ. of California, Riverside 
Publicity & 

Local Arrangements Chain 

Matthew Barth 

Univ. of California, Riverside 


Workshop on Applications of Computer Vision, IEEE Computer Society, 1730 
Massachusetts Ave., NW, Washington, DC, 20036. 

IMPORTANT DATES: 

June 1, 1992: Paper Submission Deadline 

July 31, 1992: Notification of Acceptance 

September 1, 1992: Final Paper Due 







IEEE COMPUTER SOCIETY 


The Awards Committee of the 
IEEE Computer Society 
solicits nominations for the 
following key society awards: 

COMPUTER PIONEER AWARD 

Outstanding individuals whose main contribution to the concepts and development 
of the computer field has been made more than 15 years ago. 

HARRY GOODE MEMORIAL AWARD 

Outstanding contributions to the information sciences, including 
seminal ideas, algorithms, computing directions, and concepts. 

ECKERT-MAUCHLY AWARD 

Awarded jointly by the ACM and the Computer Society for outstanding 
contributions to the field of computer architecture. 

IV. WALLACE MCDOWELL AWARD 

Outstanding recent theoretical, design, educational, practical, or other 
tangible innovative contributions to computer science and engineering. 

TECHNICAL ACHIEVEMENT AWARD 

Outstanding and innovative contributions to the field of computer 
science or computer technology within the past 15 years. 

COMPUTER ENTREPENEUR AWARD 

Managers whose vision and leadership have resulted in growth of some segment 
of the computer industry. Contributions shall have occurred more than 15 years ago. 

RICHARD E. MERWIN DISTINGUISHED SERVICE AWARD 

Highest service award granted by the Computer Society, in recognition of outstanding 
service to the profession at large, including service to the Computer Society or its 
predecessor organizations. Nominee must be a Computer Society member. 

TAYLOR BOOTH AWARD 

Recognizes individuals for their outstanding record in computer science and engineering. 

Criteria include achieving recognition as a teacher of reknown in a relevant course; writing 
an influential text in computer science and engineering; leading, inspiring, or providing 
significant educational content during the creation of a curriculum in the field; and inspiring 
others to a career in computer science and engineering education. 


Deadlines: Nomination deadline for all awards: September 15. Send a letter giving details and any 
supporting documentation to the Awards Committee chairman: 


M IEEE COMPUTER SOCIETY 


Ralph J. Preiss 
12 Colburn Drive 
Poughkeepsie, NY 12603 
E-mail: R.PREISS@compmail.com 
FAX: (914) 462-1858 
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Boehm outlines DoD Software Technology Strategy 

Ware Myers, Contributing Editor 


The United States Department of 
Defense hopes to reduce software 
life-cycle costs by a factor of two over 
the next eight years, keynoter Barry 
W. Boehm told some 200 software 
managers and technologists assembled 
in San Diego for the 1992 Achieving 
Quality Software Debate sponsored 
by the Society for Software Quality. 
Boehm said this goal means that a 
typical system or upgrade started in 
the year 2000 would cost half as much 
as the same capability would cost us¬ 
ing 1992 technology and practices. 

As director of the Software and In¬ 
telligent Systems Technology Office 
of the Defense Advanced Research 
Projects Agency, Boehm had a large 
part in drafting the 400-page Software 
Technology Strategy report on which 
he based his speech. Copies of the 
draft report became available for 
comment January 30, the day of his 
talk. The DoD plans a three-day fo¬ 
rum at Tysons Corner, Virginia, near 
Washington, DC, beginning March 31, 
for feedback from the defense soft¬ 
ware community. 

As a second goal, DoD intends to 
reduce software problem rates by a 
factor of 10, Boehm said. This reduc¬ 
tion refers both to the defect rates for 
delivered software and to the level of 
incidence of software problems as the 
major cause of system acquisition 
problems. 

“Software is hard to acquire and 
support,” Boehm noted. He quoted 
the commander of the Electronic Sys¬ 
tems Division, the unit responsible for 
acquiring hard- and software systems 
for the US Air Force, as saying, “Of 
every 10 projects I have that are in 
trouble, seven are in trouble because 
of software.” 

As a third goal, DoD wants to 
achieve new levels of mission capabili¬ 
ty and interoperability through better 
software. 

Software will continue to be a sub¬ 
stantial activity of the department 
even though the overall military bud¬ 
get is declining. One approach, for ex¬ 
ample, reduces the number of hard¬ 
ware units. If only one unit is built, 
however, it will still need complete 


software. “So we still have software as 
a big target of opportunity for addi¬ 
tional savings,” Boehm said. 

Potential savings. Without an active 
effort to reduce software costs, they 
are likely to rise from the present $24 
billion per year to about $52 billion 
over the next 15 years. The Software 
Technology Strategy report sets forth 
two alternative programs to check this 
rise. 

The “current program” can be im¬ 
plemented within currently pro¬ 
grammed budget levels, representing 
expenditures at a constant level of 
about $195 million per year. If the 
program is successful, total software 
costs will rise to $30 billion. The re¬ 
turn on investment of this program is 
27 to 1; its net present value is $34 bil¬ 
lion. This program, however, would 
reduce costs by the year 2000 by less 
than the factor-of-two goal. Its cost- 
reduction factor is calculated to be in 
the 1.3 to 1.4 range. 

The “achievable program” contem¬ 
plates still greater expenditures on 
software research, methodologies, and 
their dissemination. Its budget would 
grow by a factor of 2.1 between 1992 
and 1997 — from $195 million to $410 
million — and thereafter at 3 percent 
per year. Under this plan, software 
costs would fall to about $12 billion 
annually by 2008. The incremental re¬ 
turn on investment, beyond the cur¬ 
rent program, would be 17 to 1. The 
incremental net present value would 
be an additional $19 billion. The 
achievable program can accomplish 
the factor-of-two cost-reduction ob¬ 
jective in the next eight years. 

Strategic themes. Several hundred 
capabilities, listed in some 40 pages of 
tables, would be required to reach 
these goals. Present capabilities fall 
short. For example, integrated CAD/ 
CAM/CAE/CASE is needed; some 
limited experimental capabilities are 
available. 

DoD has expressed these needs in 
terms of five broad themes. It calls the 
first one “reuse and megaprogram¬ 
ming.” The return-on-investment 


analysis indicates that the greatest 
savings will come from reusing soft¬ 
ware assets. DoD expects its current 
reuse and repository initiatives to 
have good payoffs, but says “they will 
be limited by the shortage of technol¬ 
ogy to support rapid and confident 
composition of software components.” 
Megaprogramming will create a new 
level of technology. “It is time to stop 
thinking about software one instruc¬ 
tion at a time and begin thinking 
about it one component at a time,” 
Boehm said. 

The department has a huge soft¬ 
ware inventory. Supporting it after de¬ 
livery is an enormous expense. Mak¬ 
ing it easier and cheaper to modify is 
the second strategic theme. Analyses 
indicate that 47 percent of the mainte¬ 
nance effort has typically been devot¬ 
ed just to understanding what the soft¬ 
ware is doing. Reengineering it into 
well-structured Ada will be a major 
emphasis. Estimated savings are sec¬ 
ond only to reuse and megaprogram¬ 
ming. 

The third theme deals with software 
process improvement. Technology im¬ 
provements “can significantly increase 
quality and reduce rework costs,” the 
report states. They can also reduce ac¬ 
quisition time and cost while improv¬ 
ing performance. Achieving these 
goals requires synergy between what 
technology provides and what man¬ 
agement can inculcate. 

Commercial software offers a sav¬ 
ings leverage by spreading develop¬ 
ment and maintenance costs across a 
much larger base than DoD alone 
provides. Therefore, DoD should mi¬ 
grate some of its software in this di¬ 
rection. “Even more cost-effective le¬ 
verage can be obtained by stimulating 
existing commercial technology prod¬ 
ucts to address DoD needs,” the re¬ 
port adds. 

Fifth, much of the software func¬ 
tionality contemplated in future mili¬ 
tary scenarios could be better 
achieved “by integrating advances in 
artificial intelligence and software en¬ 
gineering technology.” One early ef¬ 
fort in this direction has been credited 
with reducing the time required for 
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force-unit plan generation and analy¬ 
sis from four days to 2.5 hours — a ca¬ 
pability that had a major impact on 
operational readiness for Operation 
Desert Storm. 

Good intentions aren’t enough. “As 

everybody in software quality knows, 
developing and publishing standards 
doesn’t get you anywhere,” the speak¬ 
er said. “There has to be some way to 
enforce [these intentions] by some 
kind of assessment capability.” 

Boehm was referring to the five 
software-process maturity levels de¬ 
veloped with DARPA financing by 
Watts Humphrey at Carnegie Mellon 
University’s Software Engineering In¬ 
stitute. Conference participants had 
already discussed these levels at some 
length. Several speakers, for example, 
had reported that assessments to date 
revealed that more than 80 percent of 
software organizations reside at matu¬ 
rity level 1. Comments from the audi¬ 
ence implied a high level of worry and 
uncertainty. 

Boehm said that DoD has already 


embarked on two steps. One is to re¬ 
inforce what the Software Engineer¬ 
ing Institute has under way, upgrading 
the maturity model. Levels 1, 2, and 3, 
where nearly all existing organizations 
reside, are fairly well defined, but the 
higher levels need further elaboration. 

The second step is “to figure out 
what DoD’s policy should be on using 
the maturity levels.” For instance, 
DoD’s Corporate Information Man¬ 
agement program, under Paul Strass- 
man, has published a memorandum 
directing its people to use maturity as¬ 
sessment and to get on a maturity im¬ 
provement curve. 

That leads to the issue of whether 
these assessments should be a source- 
selection criterion. That question is 
under study, and the issue worries 
software contractors. 

Contractors, in turn, complain that 
DoD acquisition organizations them¬ 
selves lack the maturity to administer 
the levels concept. “A number of peo¬ 
ple here have observed that if you 
have a level 3 contractor and a level 1 
acquisition organization, you are not 


going to get a level 3 system,” Boehm 
noted. “We are gearing up to create a 
cadre of expert reviewers trained in 
risk assessment and things like that to 
participate on Defense Acquisition 
Board committees.” 

In the longer run, Boehm plans a 
study that will try to correlate the link 
between the score on maturity assess¬ 
ment and actual ability to develop 
software. Another study would try to 
find out how long it takes organiza¬ 
tions to progress from one level to the 
next higher level. “How fast can an 
organization progress along that 
curve?” Boehm asked. 

One chapter of the new report sum¬ 
marizes the most notable of the previ¬ 
ous DoD studies of this subject. “DoD 
has been studying what to do about 
software technology for a long time,” 
it says. Boehm hopes that this study 
will be more successful, partly because 
“it has been produced by and has the 
commitment of the software technolo¬ 
gy managers who will be responsible 
for implementing its recommenda¬ 
tions.” 




Advanced Placement 
Dedicated to Educational Excellence 
for Nearly Four Decades 

Faculty Consultants for the AP Reading 

Each year, the College Board’s Advanced Placement (AP"0 
Program gives hundreds of thousands of exceptionally able high 
school students an opportunity to take rigorous college-level courses 
and appropriate exams in 16 disciplines. More than 2,900 colleges 
and universities offer credit or advanced standing to students based 
on their exam performance. For six days in June, more than 2,000 
college faculty and AP teachers from across North America gather 
in the Princeton area and at Clemson University at the annual AP 
Reading to evaluate and score students’ programs. The participants 
also exchange ideas and contribute suggestions about their 
discipline, their courses, and the AP Examinations. Participants are 
paid honoraria, provided with housing and meals, and reimbursed 
for travel expenses. 

Applications are now being accepted for Faculty Consultants to 
the College Board’s Advanced Placement Readings in Computer 
Science. Applicants should currently be teaching or directing 
instruction for the first-year college course in Computer Science 
requiring the use of Pascal. 

For an application or additional information, please contact: 
Dr. Walt MacDonald, Director, Advanced Placement Program, 
Educational Testing Service, Rosedale Rd. 02-E, Princeton, NJ, 
08541. Educational Testing Service is an Equal Opportuni¬ 
ty/Affirmative Action Employer and especially encourages i 
and women to apply. 


COMPUTER COMMUNICATIONS: 

Architectures, Protocols, and Standards 
(3rd Edition) 

edited by William Stallings 

This third edition is a major revision surveying the moti¬ 
vating factors and design principles for a communication 
architecture. The tutorial devotes considerable attention 
to the OS1 model, discusses the framework used to develop 
protocols, and explores communication system design. 


The book contains 29 papers, including 24 new ardcles, 
that provide a broad overview of communication protocols. 
Among the new topics are Signaling System Number 7, 
frame relay, and ISDN call control. Other new articles cover 
the IEEE 802.6 MAN standard, lightweight transport 
protocols, internetwork routing protocols, and application- 
level protocols and standards, and more current articles on 
a number of protocols have replaced earlier versions from 
the second edition. 


1—800—CS—BOOKS 
FAX (714) 821—4010 

in California (714) 821-8380 




















PRELIMINARY CALL FOR PAPERS 

Second International Conference on 
Parallel and Distributed Information Systems 
(Issues, Architectures, and Algorithms) 

January 20-23,1993 

Hyatt Islandia Hotel on Mission Bay, San Diego, California 
Sponsors: ACM SIGMOD*, IEEE Computer Society 


SCOPE 

The scope of this conference covers parallel and distributed systems for database, large-scale knowledge base, and infor¬ 
mation management. Specific aspects of such parallel or distributed data systems include, but are not limited to, the 
theory and the practice of: 


• Distributed Databases 

• Active and Real-Time Databases 

• Data Distribution and Replication 

• Data Integration 

• Heterogeneous and Multidatabase Systems 

• Performance Evaluation 

• Reliability and Availability 


• Parallel Database System Architectures 


• Large-Scale Knowledge Base Management 

• Distributed and Parallel Object Management 


• High-Performance Storage Systems 

• Parallel and Distributed File Systems 

• Query Processing and Optimization 

• Parallel Database Algorithms 


• Transaction Models and Management 


INSTRUCTIONS 

Original papers on the above topics are invited. These should be no longer than 25 double-spaced pages or 8000 words. 
Please submit six copies to reach one of the program co-chairs at the following addresses by June 15,1992: 


Patrick Valduriez 
(Re: PDIS-2) 

INRIA, Rocquencourt 
78153 Le Chesnay Cedex 
France 


Michael Carey (Re: PDIS-2) 
Computer Sciences Department 
University of Wisconsin 
1210 West Dayton Street 
Madison, WI 53706 USA 


In addition, authors of papers should send electronic mail to pdis2@cs.wisc.edu with the title of the manuscript, authors’ 
names (without affiliations), and an abstract limited strictly to a length of 80 words. (The full manuscript may have as 
long an abstract as you wish, but please adhere strictly to the length limit in the electronic version). If you do not have 
access to electronic mail, send the above information with the manuscript on a separate sheet of paper. In any event, this 
information must be supplied and must reach its destination by June 15, 1992. Finally, authors will be interested to 
know that a special issue of The VLDB Journal containing the best papers from the PDIS conference is being planned. 

To promote cross-fertilization between works in progress, short synopses of substantial projects are also invited. These 
should be 4-5 double-spaced pages, or 1000-1500 words, containing enough information for the program committee to 
understand the scope of the problem being addressed and evaluate the novelty of the proposed solution. The current 
status of the project should also be indicated. Time will be provided in the program to discuss innovative aspects of 
selected projects. Please submit six copies of each project synopsis to reach one of the program co-chairs by June 15, 
1992. 


— IMPORTANT DATES — 


No Papers Accepted After 
Notification to Authors 


Papers Officially Due 


Camera-Ready Copy Due 
Tutorials and Conference 


June 15, 1992 
June 22, 1992 
September 14,1992 
October 12,1992 
January 20-23,1993 


Sponsorship approvals pending. 
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CALL FOR PAPERS 


IEEE Software seeks articles for 
publication in 1992 issues focusing on 
results and experience useful to practitio¬ 
ners, particularly on the following topics: 
software renovation, work-group comput¬ 
ing, maintenance under the object-oriented 
paradigm, postmortem analysis of software 
projects (from both technical and manage¬ 
ment perspectives), embedded systems 
programming and development, industrial 
experiences with Ada and C++, human fac¬ 
tors issues for software developers, and use 
of CASE tools in industrial development. 
Submit eight copies of articles to Carl 
Chang, IEEE Software , 1120 Science and 
Eng. Offices, MC 154, Univ. of Illinois, 
Chicago, IL 60680, Internet ckchang@ 
uicbert.eecs.uic.edu. For detailed author 
guidelines, call Karen Potes at (714) 821- 
8380. IEEE Software also seeks software 
developers to write 1,000- to 3,000-word 
reviews on new software packages for the 
magazine’s Toolbox department. If you are 
interested, send a brief description of your 
position, company, education/training, 
field(s) of product interest, and software 
development environment to IEEE Soft¬ 
ware, Toolbox Editor, 10662 Los Vaqueros 
Cir., Los Alamitos, CA 90720, e-mail 
chad% prevue@uunet.uu.net. 

Fourth Int’l Workshop on Foundations of 
Models and Languages for Data and Ob¬ 
jects: Oct. 19-23,1992, Volkse, Germany. 
Cosponsors: Gesellschaft fur Informatik, 
European Assoc, for Theoretical Comput¬ 
er Science. For submittal requirements, 
contact Udo Lipeck, Inst, fur Informatik, 
Univ. of Hannover, Lange Laube 22, D-W- 
3000, Hannover 1, Germany, phone 49 
(511) 762-4950, e-mail ul@informatik. 
uni-hannover.de. 

Int’l J. on Artificial Intelligence Tools, 

beginning publication this year, seeks pa¬ 
pers emphasizing research, design, devel¬ 
opment, and testing of AI tools. For infor¬ 
mation and submittal requirements, con¬ 
tact Nikolaos G. Bourbakis, SUNY at 
Binghamton, Electrical Eng. Dept., Bing¬ 
hamton, NY 13902, phone (607) 777-2165 
or 771-4033, fax (607) 777-4822, e-mail 
bourbaki@bingvaxu.cc.binghamton.edu. 

JICSLP 92, Joint Int’l Conf. and Symp. on 
Logic Programming: Nov. 9-13, 1992, 
Washington, DC. Cosponsors: Assoc, for 
Logic Programming, Univ. of Maryland 
Inst, for Advanced Computer Studies. Sub¬ 
mit six copies of 200-word abstract and 
5,000-word (maximum length) manuscript 
by Mar. 20,1992, to Krzysztof R. Apt, 

CWI, Kruislaan 413,1098 SJ Amsterdam, 
The Netherlands. 

Fifth ISMM Int’l Conf. on Parallel and 
Distributed Computing and Systems: Oct. 


Call for articles and referees for Computer 




Computer seeks 


articles for inclusion in a future special issue. 


Multichip modules has been selected as the theme for the April 1993 issue. 
Manuscripts reporting survey, original research, design and development, and 
applications of MCM technology are sought immediately. See p. 101 of the De¬ 
cember 1991 issue for more details. 

A 300-word abstract of the manuscript must be submitted by Apr. 15, 1992; 14 
copies of the full manuscript are due by June 15, 1992; notification of decisions 
is set for Oct. 15, 1992; and the deadline for submittal of the final version of each 
manuscript is Dec. 1, 1992. 

Submissions and questions should be directed to P.R. Mukund, Dept, of Elec¬ 
trical Eng., Rochester Inst, of Tech., 1 Lomb Memorial Dr., Rochester, NY 14623, 
phone (716) 475-2174, e-mail prmee@ritvax.isc.rit.edu; or J.F. McDonald, Dept, 
of Electrical Eng., Rensselaer Polytechnic Inst., Troy, NY 12180, phone (518) 
276-2919, e-mail mcdonald@unix.cie.rip.edu. 


For submittal to Computer, manuscripts must not have been previously pub¬ 
lished or currently submitted for publication elsewhere. Each manuscript should 
be no more than 32 typewritten, double-spaced, single-sided pages long, includ¬ 
ing all text, figures, and references. Each of the 14 copies submitted should in¬ 
clude a page that contains the title of the article, the full name(s) and affiliation(s) 
of the author(s), complete postal and electronic address(es) of all the authors as 
well as their telephone and fax number(s), a 300-word abstract, and a list of key¬ 
words identifying the central issues of the manuscript’s contents. The final manu¬ 
script should be approximately 8,000 words in length and contain no more than 
12 references. 

If you are willing to review articles for any special issue, please send a note 
listing your research interests to Jon T. Butler, editor-in-chief of Computer, at the 
Dept, of Electrical and Computer Eng., Naval Postgraduate School, Code EC/Bu, 
Monterey, CA 93943-5004, Internet butler@ece.nps.navy.mil. 


1-3,1992, Pittsburgh. Sponsors: Int’l Soc. 
for Mini and Microcomputers, Pittsburgh 
Supercomputing Center. Submit four cop¬ 
ies of manuscript by Mar. 25,1992, and 
camera-ready version by July 31,1992, to 
Rami Melhem, Computer Science Dept., 
Univ. of Pittsburgh, Pittsburgh, PA 15260, 
phone (412) 624-8426, e-mail melhem@cs. 
pitt.edu. 

ATS 92, First Asian Test Symp.: 

Nov. 26-27, 1992, Hiroshima, Japan. 
Submit five copies of 50-word abstract by 
Mar. 28,1992, and camera-ready copy by 
July 25,1992, to Hideo Fujiwara, Comput¬ 
er Science Dept., Meiji Univ., 1-1-1 Hi- 
gashimita, Tama-ku, Kawasaki 214, Japan, 
fax 81 (44) 934-7912, e-mail fujiwara@cs. 
meiji.ac.jp. 

Second Golden West Int'l Conf. on Intelli¬ 
gent Systems: June 1-3,1992, Reno, Nev. 
Sponsor: Univ. of Nevada. Submit two- to 
three-page abstract by Mar. 30,1992, to 
Carl G. Looney, Computer Science Dept., 
Univ. of Nevada, Reno, NV 89577, phone 
(702) 784-4313, fax (702) 784-1766, e-mail 
looney@mammoth.cs.unr.edu. 


(WKh ISSRE 92, Third Int’l Symp. on Soft- 
ware Reliability Eng.: Oct. 7-9,1992, 
Research Triangle Park, N.C. Cosponsors: 
IEEE Computer Soc. Technical Commit¬ 
tee on Software Eng. et al. Submit five 
copies of full paper by Mar. 31,1992, and 
camera-ready version by Aug. 1,1992, to 
John C. Munson, Computer Science Div., 
Univ. of West Florida, Pensacola, FL 
32514, phone (904) 474-2989, e-mail 
jmunson@dcsll9.dcsnod.uwf.edu; or Taghi 
M. Khoshgoftaar, Computer Science and 
Eng. Dept., Florida Atlantic Univ., Boca 
Raton, FL 33431, phone (407) 367-3994, 
e-mail taghi@cse.fau.edu. 

© Visualization 92: Oct. 19-23,1992, 
Boston. Sponsor: IEEE Computer 
Soc. Technical Committee on Computer 
Graphics. Submit four copies of 5,000- 
word paper by Mar. 31,1992, to Gregory 
M. Nielson, Arizona State Univ., Rural 
Rd. and University Ave., Tempe, AZ 
85287-5406, phone (602) 965-2785, e-mail 
nielson@enuxva.eas.asu.edu. 


J. of Computer and Software Eng. plans a 
special issue on reliable software in Janu- 
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ary 1993. Publisher: Ablex. Submit five 
copies of full manuscript by Mar. 31,1992, 
to Pradip K. Srimani or James M. Bieman, 
Computer Science Dept., Colorado State 
Univ., Ft. Collins, CO 80523, phone (303) 
491-7097 or 7096, fax (303) 491-6639 or 
2293, e-mail srimani@cs.colostate.edu or 
bieman@cs.colostate.edu. 


11th Int'l Conf. on the Entity Relationship 
Approach: Oct. 7-9,1992, Karlsruhe, Ger¬ 
many. Cosponsors: Gesellschaft fur Infor- 
matik, ER Inst. Submit four copies of pa¬ 
per (6,000-word maximum) by Mar. 31, 
1992, to A.M. Tjoa, Inst, of Statistics and 
Computer Science, Information Systems 
Dept., Univ. of Vienna, Liebiggasse 4/3-4, 
A-1010 Vienna, Austria, phone 43 (1) 43- 
23-67, fax 43 (1) 43-01-97, e-mail 
A4423dab@awiunil 1 .bitnet. 


Supercomputing 92: Nov. 16-20, 

L992, Minneapolis. Cosponsor: 

ACM. Submit manuscript by Apr. 1, 1992, 
to Ann Hayes, Los Alamos Nat’l Lab, Bi¬ 
kini Rd., MS B287, Los Alamos, NM 
87545, phone (505) 665-4506, fax (505) 
665-4361, e-mail ahh@lanl.gov. 

IEEE Design & Test of Computers 

seeks papers (20 double-spaced pag¬ 
es, including figures) on the design and test 
of megabit memories for its March 1993 
special issue. Submit a 300-word abstract, 
keywords, and your mail and e-mail ad¬ 
dresses along with six copies of the paper 
before Apr. 1,1992, to Manuel d’Abreu, 
GE R&D, 1 River Rd., PO Box 8, KW- 
C308, Schenectady, NY 12301, phone (518) 
387-7097, fax (518) 387-5299, e-mail 
dabreu@crd.ge.com. 


CSM 92,1992 Conf. on Software 
Maintenance: Nov. 9-12, 1992, Orlan¬ 
do, Fla. Submit five copies of 250-word ab¬ 
stract and 1,000- to 5,000-word paper by 
Apr. 1,1992, and the final version by Sept. 
1,1992, to Marc Kellner, Software Eng. 
Inst., Carnegie Mellon Univ., Pittsburgh, 
PA 15213-3890, phone (412) 268-7721, fax 
(412) 268-5758, e-mail mik@sei.cmu.edu. 


Int’l Workshop on Structural and Syntactic 
Pattern Recognition: Aug. 26-28,1992, 
Bern, Switzerland. Sponsor: Int’l Assoc, 
for Pattern Recognition. Submit three cop¬ 
ies of paper (15-page maximum) by Apr. 1, 
1992, and revised version by Aug. 26,1992, 
to Horst Bunke, Inst, fiir Informatik und 
angewandte Mathematik, Univ. of Bern, 
Langgassstrasse 51, CH-3012 Bern, Swit¬ 
zerland, phone 41 (31)654451 or 658681, 
fax 41 (31) 653965, e-mail bunke@iam. 
unibe.ch (no electronic submittals). 


SIGDoc 92,10th SIGDoc Int’l Conf.: Oct. 
13-16,1992, Ottawa, Canada. Sponsors: 
ACM Special Interest Group on Docu¬ 
mentation, Northern Telecom and Bell- 
Northern Research. Submit proposal by 
Apr. 3,1992, to Assoc, for Computing Ma¬ 
chinery, 11 W. 42nd St., New York, NY 
10036, phone (212) 869-7440; or BNR, 
(613) 763-2134, fax (613) 763-2626, e-mail 
sigdoc92@bnr.ca. 


POS 5, Fifth Int’l Workshop on Persistent 
Object Systems: Sept. 1-4, 1992, San Mini- 
ato, Pisa, Italy. Cosponsors: Univ. of Pisa, 
Univ. of St. Andrews. Submit four copies 
of complete paper by Apr. 3,1992, to Ron 
Morrison, Computer Science Dept., Univ. 
of St. Andrews, St. Andrews KY169SS, 

UK, fax 44 (334) 77068, e-mail pos5@cs. 
st-and.ac.uk. 

21CSQ, Second Int’l Conf. on Software 
Quality: Oct. 5-7,1992, Triangle Research 
Park, N.C. Sponsor: Am. Soc. for Quality, 
Software Div. Submit three copies of ab¬ 
stract and author biography by Apr. 6, 
1992, to Sue McGrath, SAS Inst., SAS 
Campus Dr., Cary, NC 27513, phone (919) 
677-8000, e-mail sassam@dev.sas.com. 

(ifi) ICCAD 92, Int’l Conf. on Computer- 
Aided Design: Nov. 8-12,1992, Santa 
Clara, Calif. Cosponsors: IEEE Circuit and 
Systems Soc., ACM. Submit 10 copies of 
one-page abstract and complete paper (20- 
page maximum) by Apr. 12,1992, and final 
version by Aug. 9,1992, to ICCAD 92, MP 
Associates, 7490 Clubhouse Rd., Suite 102, 
Boulder, CO 80301, phone (303) 530-4562. 

ECAI 92 Workshop on Model-Based Rea¬ 
soning: Aug. 3-7,1992, Vienna. Submit 
four copies of extended abstract by Apr. 

13,1992, and camera-ready version by 
June 15,1992, to Gerhard Friedrich, Infor¬ 
mation Systems Dept., Vienna Univ. of 
Tech., Paniglgasse 16, A-1040 Vienna, 
Austria, phone 43 (1) 58801-6129, fax 43 
(1) 5055304, e-mail friedrich@vexpert.dbai. 
tuwien.ac.at. 


TAI92, Fourth Int’l IEEE Conf. on 
Tools with Artificial Intelligence: 

Nov. 10-13,1992, Arlington, Va. Submit 
five copies of full paper by Apr. 15,1992, 
to H.E. Stephanou, New York State Cen¬ 
ter for Advanced Tech, in Automation and 
Robotics, Rensselaer Polytechnic Inst., 
Troy, NY 12180-3590, phone (518) 276- 
6156 or (518) 276-6965, fax (518) 276-4897, 
e-mail hes@cat.rpi.edu. 


ICSC 92, Second Int’l Computer Sci- 
W ence Conf.: Dec. 13-16,1992, Hong 
Kong. Sponsor: IEEE Hong Kong Section 
Computer Chapter. Submit five copies of 
5,000-word (maximum length) manuscript 
by Apr. 15,1992, and camera-ready ver¬ 
sion by Sept. 15,1992, to Frederick H. Lo- 
chovsky. Computer Science Dept., Hong 
Kong Univ. of Science and Tech., Clear 
Water Bay, Kowloon, Hong Kong, fax 
(852) 358-1477, e-mail fred@uxmail.ust.hk; 
or Dennis C. Tsichritzis, Centre Universi- 
taire d’lnformatique, University de 
Geneve, 12, rue du Lac, CH 1207 Geneve 
(Eaux-Vives), Switzerland, fax 41 (22) 735- 
3905, e-mail dt@cui.unige.ch. 


KBSE 92, Seventh Knowledge-Based Soft¬ 
ware Eng. Conf.: Sept. 20-23,1992, Tysons 
Corner, Va. Sponsor: Rome Lab. Submit 
six copies of paper (6,000-word maximum) 
by Apr. 15,1992, and camera-ready ver¬ 
sion by July 24,1992, to W. Lewis Johnson, 
Univ. of Southern California, Information 


Sciences Inst., 4676 Admiralty Way, Mari¬ 
na del Rey, CA 90292-6695, phone (310) 
822-1511, fax (310) 823-6714, e-mail 
johnson@isi.edu. 


Fifth Int’l Workshop on Protocol Test Sys¬ 
tems: Sept. 28-30, 1992, Montreal. Submit 
five copies of paper (12-page maximum) or 
position statement (3-page maximum) by 
Apr. 15,1992, to Gregory V. Bochmann, 
Rachida Dssouli, or Anindya Das, Univ. 
de Montreal, Dept. d’lRO, CP 6128, succ. 
A, Montreal, Que., Canada H3C 3J7, fax 
(514) 343-5834, e-mail iwpts@niro. 
umontreal.ca. 

/. of Computer and Software Eng. seeks 
papers on varied topics and applications 
for inclusion in 1993 issues No. 2 and No 3. 
Publisher: Ablex. Submit five copies of full 
manuscript by Apr. 17,1992, to K.K. Park, 
Computer Science Dept., US Naval Acade¬ 
my, Annapolis, MD 21402, phone (410) 
267-3037, fax (410) 267-4883, e-mail eun@ 
usna.navy.mil. 

FPL 92, Second Int'l Workshop on Field- 
Programmable Logic and Applications: 

Aug. 31-Sept. 2,1992, Vienna. Sponsors: 
Vienna Univ. of Tech., Univ. of Kaiser¬ 
slautern. Submit 22 copies of camera-ready 
paper by Apr. 19,1992, to Herbert Griin- 
bacher, Vienna Univ. of Tech., Treitl- 
strasse 3, A-1040, Vienna, Austria, phone 
43 (1) 58801-8150, fax 43 (1) 569697, e-mail 
herbert@vlsivie.tuwien.ac.at; or Reiner 
Hartenstein, Univ. of Kaiserslautern, PO 
Box 3049, D-W-6750 Kaiserslautern, Ger¬ 
many, phone 49 (631) 205-2606, fax 49 
(631) 205-2640, e-mail hartenst@rhrk. 
uni-kl.de. 


(£ji| 17th Conf. on Local Computer Net- 

vt? works: Oct. 11-14,1992, Minneapolis. 
Sponsor: IEEE Computer Soc. Technical 
Committee on Computer Comm. Submit 
five copies of 250-word abstract and full 
paper by Apr. 20,1992, and camera-ready 
version by Aug. 3,1992, to Steve Bell, 
Hughes LAN Systems, MS 392,1072 S. 
Saratoga Svale Rd., San Jose, CA 95129, 
phone (415) 966-7926, fax (415) 966-7990, 
e-mail sbell@hls.com. 

ACM SIGSoft 92, Fifth Symp. on Software 
Development Environments: Dec. 9-11, 
1992, Washington, DC. Submit six copies 
of abstract and full paper (maximum 
length 6,000 words) by Apr. 21,1992, and 
camera-ready paper by Sept. 1,1992, to 
Herbert Weber, Fachbereich Informatik, 
Univ. of Dortmund, Baroperstrasse 301, 
4600 Dortmund 50, Germany. 

KR 92, Third Int’l Conf. on Principles of 
Knowledge Representation and Reason¬ 
ing: Oct. 26-29,1992, Cambridge, Mass. 
Sponsors: Am. Assoc, for Artificial Intelli¬ 
gence et al. For submittal-requirement de¬ 
tails, contact William Swartout, Informa¬ 
tion Sciences Inst., Univ. of Southern 
California, 4676 Admiralty Way, Marina 
del Rey, CA 90292-6695, phone (310) 822- 
1511, fax (310) 823-6714, e-mail swartout@ 
isi.edu; or Bernhard Nebel, DFKI, Stuhl- 
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stazenhausweg 3, D-W-6600 Saarbruecken, 
Germany, phone 49 (681) 302-5254, fax 49 
(681) 302-5341, e-mail nebel@dfki. 
uni-sb.de. The submittal deadline is Apr. 

21.1992. 

Second Workshop on Management 

of Replicated Data: Nov. 12-13,1992, 
Monterey, Calif. Sponsor: IEEE Computer 
Soc. Technical Committee on Operating 
Systems and Application Environments. 
Submit 12 copies of position statement (2 
to 4 double-spaced pages) by Apr. 24, 

1992, to Hector Garcia-Molina, Computer 
Science Dept., Stanford Univ., Stanford, 
CA 94305, phone (415) 723-0685, e-mail 
hector@cs.stanford.edu. 

AICS 92, Fourth Irish Conf. on Artificial 
Intelligence and Cognitive Science: Sept. 
10-11, 1992, Limerick, Ireland. For submit¬ 
tal-requirement details and other informa¬ 
tion, contact Kevin Ryan, Computer Sci¬ 
ence and Information Systems Dept., Univ. 
of Limerick, Ireland, phone 353 (61) 33-36- 
44, fax 353 (61) 33-03-16, e-mail aics92@ul. 
ie. The submittal deadline is Apr. 24,1992. 

EWSPT 92, Second European Workshop 
on Software Process Tech.: Sept. 7-8, 1992, 
Trondheim, Norway. Cosponsors: Assoc. 
Francaise pour la Cybernetique Econo- 
mique et Technique et al. Submit four cop¬ 
ies of full paper (6,000-word maximum) by 
Apr. 25,1992, and camera-ready paper by 
.lune 28,1992, to Jean-Claude Derniame, 
Centre de Recherche en Informatique de 
Nancy, Campus scientifique B.P. 239, 
F-54506 Vandoeurve Les Nancy, France, 
phone 33 (83) 413-052, fax 33 (83) 413-079, 
e-mail derniame@loria.crin.fr. 

Crypto 92: Aug. 16-20,1992, Santa 

Barbara, Calif. Sponsor: Int’l Assoc, 
of Cryptologic Research. Submit 12 copies 
of detailed abstract (not a full paper) by 
Apr. 27,1992, and revised version by July 

20.1992, to Ernest F. Brickell, Div. 1423, 
Sandia Nat’l Labs, Albuquerque, NM 
87185, phone (505) 845-7655, fax (505) 
845-7442, e-mail efbrick@cs.sandia.gov. 

ICARCV 92, Second Int’l Conf. on 

Automation, Robotics, and Comput¬ 
er Vision: Sept. 15-18,1992, Singapore. 
Cosponsors: Singapore Institution of Engi¬ 
neers et al. Submit four copies of 300- to 
500-word summary on neural networks in 
engineering and scientific applications by 
Apr. 30, 1992, and final manuscript by 
June 30,1992, to Yoshiyasu Takefuji, Elec¬ 
trical Eng. Dept., Case Western Reserve 
Univ., Cleveland, OH 44106, phone (216) 
368-6430, fax (216) 368-2668, e-mail 
takefuji@axon.eeap.cwru.edu; and submit 
four copies on other subjects to ICARCV 
Secretariat, Associated Conventions and 
Exhibitions, 204 Bukit Timah Rd., #04-00, 
Boon Liew Bldg., Singapore 0922, phone 
(65) 799-5470, fax (65) 791-2687, e-mail 
emital@ntuvax.bitnet. 

ISCIS 7, Seventh Int’l Symp. on 

Computer and Information Sciences: 

Nov. 2-4, 1992, Antalya, Turkey. Cospon¬ 


sors: IEEE Computer.Soc. Turkey Chapter 
et al. Submit three copies of 10-page paper 
or four-page short communication by May 

1.1992, to Erol Gelenbe, Ecole des Hautes 
Etudes en Informatique, 45 rue des Saints- 
Peres, 75006 Paris, France, phone 33 (1) 
4286-2136, fax 33 (1) 4286-2231, e-mail 
erol@ehei.ehei.fr. 

(£j)I RTSS 92,13th IEEE Real-Time Sys- 
terns Symp.: Dec. 2-4, 1992, Phoenix, 
Ariz. Sponsor: IEEE Computer Soc. Tech¬ 
nical Committee on Real-Time Comput¬ 
ing. Transmit synopsis or 80-word abstract 
by May 1,1992, to rtss92@cis.upenn.edu 
and submit five copies of paper (5,000- 
word maximum) to Susan Davidson, Com¬ 
puter and Information Science Dept., 

Univ. of Pennsylvania, Philadelphia, PA 
19104-6389. Submit camera-ready paper to 
Davidson by Sept. 15,1992. 

Sixth Int'l Conf. on Modeling Techniques 
and Tools for Computer Performance 
Modeling: Sept. 16-18, 1992, Edinburgh, 
Scotland. Sponsors: Int’l Federation for In¬ 
formation Processing Working Group 7.3, 
British Computer Soc. Submit complete 
paper by May 1,1992, to Margaret Davis, 
Edinburgh Univ., Edinburgh EH9 3JZ, 
Scotland, phone 44 (31) 650-5128, fax 44 
(31) 667-7209, e-mail mda@cs.ed.ac.uk. 

ICM 92, Int’l Conf. on Microelectronics: 

Dec. 19-21,1992, Monastir, Tunisia. Sub¬ 
mit three copies of 35-word abstract and 
500-word summary by May 1,1992, and fi¬ 
nal four-page extended abstract bv Sept. 

15.1992, to M.I. Elmasry, VLSI Group, 
Univ. of Waterloo, Waterloo, Ont., Cana¬ 
da N2L 3G1, phone (519) 885-1211, ext. 
3753, fax (519) 746-5195, e-mail elmasry® 
vlsi.uwaterloo.ca (for North Am. and Eu¬ 
rope); or R. Tourki, Faculte des Sciences, 
Route de Kaironan, 5000 Monastir, Tuni¬ 
sia, phone (216) 3-61-766, fax (216) 3-62- 
873 (for all other areas). 

Fifth Digital Signal Processing Workshop: 

Sept. 13-16,1992, Starved Rock State Park, 
Ill. Sponsor: IEEE Signal Processing Soc. 
Submit four copies of two-page summary 
by May 1,1992, to Robert A. Gabel, Rm. 
M-203, MIT Lincoln Lab, Lexington, MA 
02173-0073. 

DFT 92, 1992 IEEE Int’l Workshop on De¬ 
fect and Fault Tolerance in VLSI Systems: 

Nov. 4-6,1992, Dallas. Submit 20 copies of 
summary by May 1,1992, and final 10-page 
manuscript by Aug. 15,1992, to Fabrizio 
Lombardi, Computer Science Dept., Texas 
A&M Univ., College Station, TX 77843- 
3112, phone (409) 845-6841, fax (409) 847- 
8578, e-mail lombardi@cs.tamu.edu. 

Int’l Workshop on Hardware-Soft- 
xU' ware Codesign: Sept. 30-Oct. 2,1992, 
Estes Park, Colo. Cosponsors: IEEE Com¬ 
puter Soc., IEEE Circuits and Systems Soc. 
Submit paper by May 4,1992, to Wayne 
Wolf, Electrical Eng. Dept., Princeton 
Univ., Princeton, NJ 08544, phone (609) 
258-1424, e-mail wolf@princeton.edu. 
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MCMC 92, IEEE Multi-Chip Mod- 
ule Conf., Mar. 17-20, Santa Cruz, 
Calif. Cosponsors: IEEE Circuits and Sys¬ 
tems Soc. et al. Contact Jean McKnight, 
Univ. of California, Santa Cruz, CA 95064, 
phone (408) 459-2303, fax (408) 459-4829, 
e-mail jean@ce.ucsc.edu; or Wayne Wei- 
Ming Dai, 313A Applied Sciences Bldg., 
Computer Eng. Dept., Univ. of California. 
Santa Cruz, CA 95064, phone (408) 459- 
4234, fax (408) 459-4829. 

Built-In Self-Test Workshop, Mar. 
18-20, Charleston, S.C. Sponsor: 
IEEE Computer Soc. Technical Commit¬ 
tee on Test Tech. Contact Richard Sed- 
mak, Self-Test Services, 6 Lindenwold 
Terr. Ambler, PA 19002, phone (215) 628- 
9700, fax (215) 628-2106. 

Second Conf. on Computers, Freedom, 

and Privacy, Mar. 18-20, Washington, DC. 
Cosponsors: ACM et al. Contact Confer¬ 
ences and Institutes Office, George Wash¬ 
ington Univ., Washington, DC 20052, 
phone (202) 994-0723, fax (202) 994-7048, 
e-mail cfp2@seas.gwu.edu. 

Int’l Workshop on Timing Issues in the 
Specification and Synthesis of Digital Sys¬ 
tems, Mar. 18-20, Princeton, N.J. Sponsor: 
ACM. Contact Sharad Malick, Princeton 
Univ., Electrical Eng. Dept., Princeton, NJ 
08544, phone (609) 258-4625, e-mail 
sharad@princeton.edu. 

Seventh Int’l Conf. on Tech, and Persons 
with Disabilities, Mar. 18-21, Los Angeles. 
Sponsor: California State Univ., North- 
ridge. Contact Disabled Student Services 
Office, CSUN, 18111 Nordhoff St. — 
DVSS, Northridge, CA 91330, phone (818) 
885-4929 or (818) 885-2578. 

Fourth Oregon Workshop on Software 
Metrics, Mar. 22-24, Portland. Ore. Co¬ 
sponsors: Portland State Univ., Oregon 
Center for Advanced Tech. Education. 
Contact Warren Harrison, Center for Soft¬ 
ware Quality Research, Computer Science 
Dept., Portland State Univ., PO Box 751. 
Portland, OR 97207-0751, phone (503) 
725-3108, fax (503) 725-3211, e-mail 
warren@cs.pdx.edu. 

Conf. on Extended Clinical Consulting by 
Hospital Computer Networks, Mar. 22-25, 

Boston. Sponsor: New York Academy of 
Sciences. Contact Conf. Dept., NYAS, 2 E. 
63rd St., New York, NY 10021, phone 
(212) 838-0230, fax (212) 888-2894. 

1992 Symp. on Optically Based Methods 
for Process Analysis and 1992 Symp. on 
Compound Semiconductor Physics and 
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Devices, Mar. 22-26, Somerset. N.J. Spon¬ 
sor: Int’l Soc. for Optical Eng. Contact 
SPIE, PO Box 10, Bellingham, WA 98227- 
0010, phone (206) 676-3290, fax (206) 647- 
1445; SPIE, Xantner Strasse 22, D-1000 
Berlin 15, Germany, phone (49) 228- 
219062; or SPIE, c/o OTO Research, 
Takeuchi Bldg., 1-34-12 Takatanobaba, 
Shinjuku-ku, Tokyo 160, Japan, phone 81 
(03) 3208-7821, fax 81 (03) 3200-2889. 

EWPC 92, European Workshop on Paral¬ 
lel Computing, Mar. 23-24, Barcelona, 
Spain. Sponsor: Commission of European 
Communities. Contact EWPC 92 Secretari¬ 
at, c/o W. Joosen, Departement Computer- 
wetenschappen, K.U. Leuven, Celestijnen- 
laan 200 A, B-3001 Heverlee-Leuven, 
Belgium, phone (32) 1620-1015, fax (32) 
1620-5308, e-mail ewpc92@cs.kuleuven. 
ac.be. 

(£f^) IPPS 92, Sixth Int’l Parallel Process¬ 
es^ jng Symp., Mar. 23-26, Beverly Hills, 
Calif. Contact Larry H. Canter, Computer 
Systems Approach, 1140 S. Raymond Ave., 
Suite B, Fullerton, CA 92631, phone (714) 
738-3414, fax (714) 738-3470. 


EDBT 92, Int'l Conf. on Extending 
Database Tech., Mar. 23-27, Vienna. 
Sponsor: IEEE. Contact Brigitte Haber- 
stroh, Inst. 184-2, Tech. Univ. of Vienna, 
A-1040 Vienna, Austria, phone 43 (1) 588- 
01/6122, fax 43 (1) 505-5304, e-mail 
haber@vexpert.dbai.tuwien.ac.at. 


DB/Expo 92 Conf., Mar. 23-27, San Fran¬ 
cisco. Sponsor: NDN Enterprises. Contact 
NDN, 289 S. San Antonio Rd., #204, Los 
Altos, CA 94022, phone (800) 2DB-EXPO 
or (415) 941-8440, fax (415) 941-2066. 


DCC 92, Data Compression Conf., 
Mar. 24-26, Snowbird, Utah. Spon¬ 
sors: IEEE Computer Soc. Technical Com¬ 
mittee on Computer Comm., NASA. Con¬ 
tact Martin Cohn, Computer Science 
Dept., Brandeis Univ., Waltham, MA 
02554, phone (617) 736-2705, fax (617) 
736-2741, e-mail marty@cs.brandeis.edu. 

(£ji| 1992 Computer-Based Systems Eng. 

Workshop, Mar. 24-26, Washington, 
DC. Sponsor: IEEE Computer Soc. Task 
Force on Computer-Based Systems Eng. 
Contact Ashok Agrawala or Phil Hwang, 
Computer Science Dept., Univ. of Mary¬ 
land, College Park, MD 20742. 


1992 Conf. on Advanced Research in VLSI 
and Parallel Systems, Mar. 25-27, Provi¬ 
dence, R.I. Cosponsors: Brown Univ., 

MIT. Contact Daniel Lopresti, Computer 
Science Dept., Box 1910, Brown Univ., 
Providence, RI 02912, phone (401) 863- 
7643, fax (401) 863-7657, e-mail dpl@cs. 
brown.edu. 


In the accompanying Calendar and adjoining Call for Papers, the IEEE 
Computer Society logo identifies the conferences the society is sponsoring 
or cooperating in. Other conferences of interest to our readers are also listed. 

The notices are published in chronological order, as space permits, and free of 
charge. 

For inclusion in the Call for Papers section, please submit the name of the 
event, date(s), location, sponsor(s), deadline for submittals, phone and fax num¬ 
bers, and — if applicable — the electronic address of the person to whom papers 
should be directed. 

For the Calendar section, please provide the event name, date(s), location, 
sponsor(s), phone and fax numbers, and — again, if applicable — the electronic 
address of the person to contact for complete information. 

Submitted information should arrive at Computer at least five weeks before 
the month of publication (i.e., for the May 1992 issue, send information for re¬ 
ceipt by March 20, 1992) to Chuck Governale, Calendar Dept., Computer, PO 
Box 3014, Los Alamitos, CA 90720-1264, fax (714) 821-4010, e-mail 
c.governale@compmail.com. 


frfjb SEDMS 92, Third Symp. on Experi- 

ences with Distributed and Multipro¬ 
cessor Systems, Mar. 26-27, Newport 
Beach, Calif. Sponsor: Usenix Assoc. Con¬ 
tact George Leach, AT&T Paradyne, MS 
LG-133, PO Box 2826, Largo, FL 34649- 
2826, phone (813) 530-2376, fax (813) 530- 
8224, e-mail reggie@pdn.paradyne.com. 

ASOM, Second Am. Symp. on Mi- 
eSp' croelectronics, Mar. 27-28, Memphis, 
Tenn. Sponsor: Memphis State Univ. Con¬ 
tact Eliayeb S. Abuelyaman, Electrical 
Eng. Dept., Memphis State Univ., Mem¬ 
phis, TN 38152, phone (901) 678-2050, fax 
(901) 678-4180. 


SETSS 92, Eighth Int’l Conf. on Software 
Eng. for Telecommunication Systems and 
Services, Mar. 30-Apr. 1, Florence, Italy. 
Sponsor: Institution of Electrical Engi¬ 
neers. Contact IEE Conf. Services, Savoy 
Place, London WC2R 0BL, UK, phone 
(071) 240-1871, fax (071) 240-7735. 


TOOLS Europe 92, Tech, of Object-Ori¬ 
ented Languages and Systems Int’l Conf., 
Mar. 30-Apr. 2, Dortmund, Germany. Co¬ 
sponsors: Societe des Outils du Logiciel 
and Georg Heeg. Contact Boris Magnus- 
son, Lund Univ. Computer Science Dept., 
PO Box 118, S-22100 Lund, Sweden, fax 
(46) 4613-1021, e-mail boris@dna.lth.se; or 
SOL, 14 rue Jean Rey, 75015 Paris, France, 
phone 33 (1) 4056-0358, fax 33 (1) 4056- 
0581. 


US Dept, of Defense Software Tech. Strat¬ 
egy Public Forum, Mar. 31-Apr. 2, Falls 
Church, Va. Sponsor: Office of the Deputy 
Director of Defense for Research and Eng. 
Contact Donna Graham, Inst, for Defense 
Analyses, 1801 N. Beauregard St., Alexan¬ 
dria, VA 22311, phone (703) 845-6616, 
e-mail graham@ida.org. 


April 1992 

/gjjjt IPCCC 92, nth IEEE Int’l Phoenix 
Conf. on Computers and Communi¬ 
cations, Apr. 1-3, Scottsdale, Ariz. Spon¬ 
sor: IEEE Comm. Soc. Contact IEEE 
IPCCC 92, PO Box 8950, Scottsdale, AZ 
85252, phone (602) 234-4477; Ralph Mar¬ 
tinez, Univ. of Arizona, Electrical and 
Computer Eng. Dept., Tucson, AZ 85721, 
phone (602) 621-6174, e-mail martinez% 
ecevax@rvax.ccit. arizona.edu; or Joseph 
Urban, Computer Science and Eng. Dept., 
Arizona State Univ., Tyler Mall-ECG 252, 
Tempe, AZ 85287-5406, phone (602) 965- 
2774, fax (602) 965-2751, e-mail jurban@ 
asuvax.eas. asu.edu. 

Third Conf. on Applied Natural Language 
Processing, Apr. 1-3, Trento, Italy. Spon¬ 
sor: Assoc, for Computational Linguistics. 
Contact Oliviero Stock, IRST, 38050 Povo, 
Trento, Italy, phone 39 (461) 814-444, fax 
39 (461) 810-851, e-mail stock@irst.it; or 
Madeleine Bates, BBN Systems and Tech¬ 
nologies, 10 Moulton St., Cambridge, MA 
02138, phone (617) 873-3634, fax (617) 
873-3776, e-mailbates@bbn.com. 

SIGCPR 92, Apr. 5-7, Cincinnati, Ohio. 
Sponsor: ACM Special Interest Group on 
Computer Personnel Research. Contact 
Thomas Ferratt, Univ. of Dayton, Decision 
Sciences Dept., 300 College Park, Dayton, 
OH 45469, phone (513) 229-2728, e-mail 
ferratt@dayton. 

Conf. on Programming Environments for 
Parallel Computing, Apr. 6-8, Edinburgh, 
Scotland. Cosponsors: Int’l Federation for 
Information Processing et al. Contact 
Rosemary Candlin, Computer Science 
Dept., Univ. of Edinburgh, King’s Bldgs., 
Edinburgh, UK EH9 3JZ, phone 44 (31) 
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CTl) 25th Simulation Symp., Apr. 6-9, Or- 

lando, Fla. Sponsor: Soc. for Com¬ 
puter Simulation. Contact Tom Kubiak, 
EDS/CPC HQ Rm. 228-25, 30601 Van 
Dyke, Warren, Ml 48090-9020, phone 
(313) 575-0886, fax (313) 575-0966. 

10th IEEE VLSI Test Symp., Apr. 6- 

9, Atlantic City, NJ. Sponsor: IEEE 
Computer Soc. Technical Committee on 
Test Tech. Contact IEEE Computer Soc., 
1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903, phone (202) 371-1013, fax 
(202) 728-0884; or Dhiraj Pradham, Univ. 
of Massachusetts, ECE Dept., Marcus 
Hall, Amherst, MA 01003, phone (413) 
545-0160, fax (413) 545-4611. 

Latin 92, Int’l Symp. on Latin Am. Theo¬ 
retical Informatics, Apr. 6-10, Sao Paulo, 
Brazil. Cosponsors: ACMet al. Contact 
Paulo Feofiloff, Univ. de Sao Paulo, Inst, 
de Matematica e Estatisticas, Caixa Postal 
20570, phone 55 (11) 813-9499, e-mail 
pfeofilo@brusp.bitnet. 

Fourth Int’l Conf. on Image Processing 
and its Applications, Apr. 7-9, Maastricht, 
The Netherlands. Sponsor: Institution of 
Electrical Engineers. Contact IEE Conf. 
Services, Savoy Place, London WC2R 0BL, 
UK, phone (071) 240-1871, fax (071) 240- 
7735. 

AM 92,1992 Automated Manufacturing 
Conf., Apr. 7-9, Greenville, S.C. Sponsor: 
South Carolina State Board for Technical 
and Comprehensive Education. Contact 
SCBTCE, 111 Executive Center Dr., Co¬ 
lumbia, SC 29210, phone (800) 553-7702, 
(803) 772-9354, or (803) 737-9354, fax 
(803) 737-9343. 

Flairs 92, Fifth Florida AI Research Symp., 
Apr. 7-10, Ft. Lauderdale, Fla. Contact 
Fred Hoffman, Math Dept., Florida Atlan¬ 
tic Univ., Boca Raton, FL 33431, phone 
(407) 367-3345, e-mail hoffman@servax. 
bitnet. 

30th Goddard Memorial Symp., Apr. 8-10, 

Alexandria, Va. Sponsor: Am. Astronauti- 
cal Soc. Contact AAS, 6352 Rolling Mill 
PI., Suite 102, Springfield, VA 22152. 

EWDC 4, Fourth European Workshop on 
Dependable Computing, Apr. 8-10, 

Prague, Czechoslovakia. Cosponsors: 
Gesellschaft ftir Informatik et al. Contact 
Karama Kanoun, LAAS-CNRS, 7, Avenue 
du Colonel Roche, 31 077 Toulouse Cedex, 
France, fax (33) 6133-6411, e-mail 
kanoun@laas.fr; or Francesca Saglietti, 

GRS, Abteilung Prozebrechner, Forschun- 
gsgelande, 8046 Garching, Germany, fax 
(49) 89-3200-4300. 

Working Conf. on Information System 
Concepts, Apr. 13-15, Alexandria, Egypt. 
Sponsor: Int’l Federation for Information 
Processing. Contact Eckhard D. Falken- 
berg, Information Systems Dept., Univ. of 
Nijmegen, Toemooiveld 1, NL-6525 ED 


CIME Design 92, First Int’l CAD/CAM/ 
CAE/CIM Conf., Apr. 13-16, Detroit. 
Sponsor: Am. Soc. of Mechanical Engi¬ 
neers. Contact ASME, 345 E. 47th St., 

New York, NY 10017, phone (212) 705- 
7470 or 7057, fax (212) 705-7674. 

Fourth Software Tech. Conf., Apr. 13-17, 

Salt Lake City. Sponsor: US Air Force 
Software Tech. Support Center. Contact 
Dana Dovenbarger, OO-ALC/TISAC, Hill 
AFB, UT 84056, phone (801) 777-7411, fax 
(801) 777-8069. 

® Third Workshop on Future Trends in 
Distributed Computing, Apr. 14-16, 

Taipei, Taiwan. Sponsor: IEEE Computer 
Soc. Technical Committee on Distributed 
Computing. Contact Stephen S. Yau, Univ. 
of Florida, Computer and Information Sci¬ 
ences Dept., 301 CSE Bldg., Gainesville, 
FL 32611-2024, phone (904) 392-1212, fax 
(904) 392-1220. 

ICCL 92, Int’l Conf. on Computer 
vSP' Languages, Apr. 20-23, San Fran¬ 
cisco. Sponsor: IEEE Computer Soc. Tech¬ 
nical Committee on Computer Languages. 
Contact Mario Barbacci, Software Eng. 
Inst., Carnegie Mellon Univ., Pittsburgh, 
PA 15213, phone (412) 268-7704, fax (412) 
268-5758, e-mail barbacci@sei.cmu.edu. 

15th IEEE Workshop on Design for 
v!?' Testability, Apr. 21-24, Vail, Colo. 
Contact T.W. Williams, IBM, PO Box 
1900, 67A/021, Boulder, CO 80301-9191, 
phone (303) 924-7692. 

Third Workshop on Workstation Op- 
erating Systems, Apr. 23-24, Key 

Biscayne, Fla. Sponsor: IEEE Computer 
Soc. Technical Committee on Operating 
Systems and Applications Environments. 
Contact Joseph Boykin, 7 Hampton Rd., 
Natick, MA 01760, phone (508) 651-8228. 

23rd Pittsburgh Conf. on Modeling and 
Simulation, Apr. 30-May 1, Pittsburgh. Co¬ 
sponsors: Univ. of Pittsburgh, IEEE et al. 
Contact William G. Vogt or Marlin H. 
Mickle, 348 Benedum Eng. Hall, Univ. of 
Pittsburgh, Pittsburgh, PA 15261. 


May 1992 

(fftj CHI 92, Conf. on Human Factors in 
Computing, May 3-7, Monterey, 
Calif. Sponsor: ACM. Contact Assoc, for 
Computing Machinery, 11 W. 42nd St., 
New York, NY 10036, phone (212) 869- 
7440. 

1992 IEEE Symp. on Research in Se- 
V5Y curity and Privacy, May 4-6, Oak¬ 
land, Calif. Sponsor: IEEE Computer Soc. 
Technical Committee on Security and Pri¬ 
vacy. Contact Deborah Cooper, Unisys, 
5731 Slauson Ave., Culver City, CA 90230, 


phone (310) 338-3727, e-mail cooper@culv. 
unisys.com. 

Second Workshop on Software Reliability, 
May 4-6, Ottawa, Canada. Cosponsors: 
IEEE Canadian Review et al. Contact 
Shirley Mills, Statistical Consulting Centre, 
Mathematics and Statistics Dept., Rm. 613 
Dunton Tower, Carleton Univ., Ottawa, 
Ont., Canada K1S 5B6, phone (613) 788- 
3984, fax (613) 788-2148, e-mail stat_ 
consulting@carleton.ca. 

(jjjj) IEEE Infocom 92,11th Conf. on 
v*?' Computer Comm., May 4-8, Flo¬ 
rence, Italy. Cosponsor: IEEE Comm. Soc. 
Contact L. Fratta, Politecnico di Milano, 
c/o Cefriel, Via Emanueii, 15, 20126 Mila¬ 
no, Italy, phone 39 (2) 2399-3578, fax 39 
(2) 2399-3587, e-mail fratta@imicefr.bitnet; 
or J. Kurose, Computer and Information 
Science Dept., Univ. of Massachusetts, 
Amherst, MA 01003, phone (413) 545- 
1585, e-mail kurose@cs.umass.edu. 

Comp Euro 92, IEEE Int’l Conf. on 

Computer Systems and Software 
Eng., May 4-8, The Hague, The Nether¬ 
lands. Cosponsors: IEEE Region 8, IEEE 
Benelux Section. Contact Patrick Dewilde, 
Delft Univ. of Tech., EE Dept., POB 5031, 
2600 GA Delft, The Netherlands, fax 31 
(15) 623-271; or G. Arink, Philips Medical 
Systems, PO Box 10000, 5680 DA Best, 

The Netherlands, phone 31 (40) 762-060, 
fax 31 (40) 762-952. 

PTW 92, Second Pacific Test Work- 
'2? shop, May 5-8, Vancouver, B.C., 
Canada. Sponsor: IEEE Computer Soc. 
Technical Committee on Test Tech. Con¬ 
tact Andre Ivanov, Electrical Eng. Dept., 
Univ. of British Columbia, 2356 Mian 
Mall, Vancouver, B.C., Canada V6T 1Z4, 
phone (604) 822-6936, fax (604) 822-5949; 
or Mani Soma, phone (206) 685-3810, fax 
(206) 543-3842. 

1992 IEEE Int’l Conf. on Robotics and 
Automation, May 10-15, Nice, France. 
Sponsor: IEEE Robotics and Automation 
Soc. Contact Harry Hayman, PO Box 3216, 
Silver Spring, MD 20918, phone (301) 236- 
5621, fax (301) 236-5621. 

ICSE 92, 14th Int’l Conf. on Soft- 

ware Eng., May 11-15, Melbourne, 
Australia. Cosponsors: IEEE Computer 
Soc. Technical Committee on Software 
Eng. et al. Contact IEEE Computer Soc., 
1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903, phone (202) 371-1013, fax 
(202) 728-0884; or A.Y. Montgomery, 
Computer Science Dept., Royal Mel¬ 
bourne Inst, of Tech., PO Box 2476V, Mel¬ 
bourne 3001, Victoria, Australia, phone 61 
(3) 660-2943, fax 61 (3) 662-1617, e-mail 
aym@goanna.cs.rmit.oz.au. 

Electro 92, May 12-14, Boston. Cospon¬ 
sors: IEEE et al. Contact Electro 92, 8110 
Airport Blvd., Los Angeles, CA 90045, 
phone (800) 877-2668. 

Ninth IEEE Workshop on Real- 

Time Operating Systems and Soft- 
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ware. May 13-14, Pittsburgh. Cosponsors: 
IEEE Computer Soc. Technical Commit¬ 
tee on Real-Time Systems, Office of Naval 
Research. Contact Marc Donner, IBM Re¬ 
search, PO Box 218, Yorktown Heights, 

NY 10598, phone (914) 784-7508 or (914) 
945-2032, fax (914) 945-1234, e-mail 
donner@watson.ibm.com. 

Workshop on Interconnections with- 

in High-Speed Digital Systems, May 
18-20, Santa Fe, N.M. Sponsor: IEEE La¬ 
sers and Electro-Optics Soc. Contact Ken 
Young, Bellcore, 445 South St., Rm. 2Q- 
150, Morristown, NY 07962-1910. 

/jjjj) ISCA 92,19th Int'l Symp. on Com- 
viz puter Architecture, May 19-21, 

Queensland, Australia. Cosponsors: IEEE, 
ACM SIGArch. Contact Jean-Lue Gaudi- 
ot, EE-Systems Dept., SAL 300, Univ. of 
Southern California, Los Angeles, CA 
90089-0781, phone (213) 740-4484 or (213) 
743-0249, fax (213) 740-4449, e-mail 
gaudiot@usc.edu or gaudiot@priam.usc. 
edu; or D. Abramson, CSIRO, 723 Swan- 
ston St., Melbourne 3000, Australia, phone 
61 (3) 282-2666,e-mail david.abramson@ 
mel.dit.csiro.au. 

Sixth Int'l Conf. on Computer Sci- 
vAz ence. May 20-22, Tunis, Tunisia. 
Sponsor: Assoc. Francaise pour la Cyber- 
netique Economique et Technique. Con¬ 
tact Montasser Ouaili, Ecole Nationale des 
Sciences de 1’Informatique, 16 Rue 8010 
Quartier Montplaisir, 1002 Tunis Belve¬ 
dere, Tunisia, phone 216 (1) 784-032, fax 
216 (1) 787-827. 

IEEE Int'l Symp. on Industrial Electron¬ 
ics, May 25-29, Xian, China. Cosponsors: 
IEEE Industrial Electronics Soc. et al. 
Contact Allen C. Chen, AT&T Bell Labs, 
Rm. 1E134A, Whippany Rd„ PO Box 903, 
Whippany Road, NJ 07981-0903; J.D. Ir¬ 
win, Electrical Eng. Dept., Auburn Univ., 
Auburn, AL 36849, phone (205) 844-1810, 
fax (205) 844-1809; or Sheng-wu Liu, Li¬ 
brary, Northwestern Polytechnical Univ., 
Xian 710071, China, phone 1 (29) 533-71 
ext. 2926, fax 1 (29) 711-959. 

ISTCS, Israeli Symp. on the Theory 
vAz of Computing and Systems, May 27- 

28, Haifa, Israel. Cosponsors: Assoc, of 
Technological Education in Electronics 
and Computer Science et al. Contact 
Michael Rodeh, Science and Tech., IBM 
Israel, Technion City, Haifa 32000, Israel, 
phone 972 (4) 296-205, fax 972 (4) 320-894. 

MVL 92,22nd Int’l Symp. on Multi- 
viz ple-Valued Logic, May 27-29, Sendai, 
Japan. Sponsors: IEEE Computer Soc. 
Technical Committee on Multiple-Valued 
Logic, Japan Research Group on Multiple- 
Valued Logic. Contact Tatsuo Higuchi, 
Electronic Eng. Dept., Tohoku Univ., 
Aoba, Aramaki, Sendai 980, Japan, phone 
81 (022) 222-1800, fax 81 (022) 263-9406, 
e-mail thiguchi@higuchi.ecei.tohoku.ac.jp; 
or S.B. Silio, Electrical Eng. Dept., Univ. 
of Maryland, College Park, MD 20742, 
phone (301) 454-6839, fax (301) 454-1837, 
e-mail silio@eng.umd.edu. 


Symp. on Assessment of Quality 
viz Software Development Tools, May 
27-29, New Orleans. Sponsor: Tulane 
Univ. Contact Judy Lee, IBM, 1000 NW 
51st. St., Boca Raton, FL 33432, phone 
(407) 982-1048; or Ez Nahouraii, IBM 
(798/089), 6321 San Ignacio Ave., San Jose, 
CA 95119, phone (408) 281-5741, e-mail 
eznah@stlvm7.iinusl.ibm.com. 

(jjjji ICCI, Fourth Conf. on Computing 
viz and Information, May 28-30, Toron¬ 
to. Contact Peter E. Lauer, Computer Sci¬ 
ence and Systems, McMaster Univ., Hamil¬ 
ton, Ont., Canada, phone (416) 525-9140. 


June 1992 

Fifth-Generation Computer Systems, 
vAz June 1-5, Tokyo. Cosponsors: Infor¬ 
mation Processing Soc. of Japan et al. Con¬ 
tact Hidehiko Tanaka, Electrical Eng. 
Dept., Univ. of Tokyo, 3-1 Hongo 7- 
chome, Bunkyo-ku, Tokyo 113, Japan, 
phone 81 (33) 3812-2111 ext. 6663, fax 81 
(33) 3818-5706, e-mail tanaka@mtl.t. 
u-tokyo.ac.jp. 

Sixth Israel Conf. on Computer Sys- 
viz terns and Software Eng., June 2-3, 

Herzliya, Israel. Sponsors: IEEE Comput¬ 
er Soc. Israel Chapter, Information Pro¬ 
cessing Assoc, of Israel. Contact Confer¬ 
ence Secretariat, Ortra, PO Box 50432, Tel 
Aviv 61500, Israel, phone 972 (3) 664-825, 
fax 972 (3) 660-952. 

® European Design for Testability 
Conf., June 2-4, Brugge, Belgium. 
Contact Thomas W. Williams, phone (303) 
924-9912; or J. Jamison, phone 32 (2) 118- 
7511. 

Euro ASIC 92, June 2-4, Paris. Con- 
v!z tact Gabriele Saucier, Laboratoire 
CSI/Institut National, Polytechnic de 
Grenoble, 46 Ave. Felix Viallet/38000 
Grenoble, France, phone (33) 76-574-687, 
fax (33) 76-503-421. 

COGANN, Combination of Genetic Algo¬ 
rithms and Neural Networks Workshop, 
June 6, Baltimore. Sponsor: IEEE Neural 
Networks Council. Contact Darrell Whit¬ 
ley, Computer Science Dept., Colorado 
State Univ., Fort Collins, CO 80523, phone 
(303) 491-5373, e-mail whitley@cs. 
colostate.edu. 

IJCNN 92, Int’l Joint Conf. on Neural Net¬ 
works, June 7-11, Baltimore. Cosponsors: 
IEEE, Int’l Neural Network Soc. Contact 
IJCNN 92, 5665 Oberlin Dr. #110, San Di¬ 
ego, CA 92121, phone (619) 453-6222, fax 
(619) 535-3880. 

/£g) DAC 92, 29th IEEE/ACM Design 
^Az Automation Conf., June 8-12, Ana¬ 
heim, Calif. Contact DAC 92, MP Associ¬ 
ates, 7490 Clubhouse Rd., Boulder, CO 
80301, phone (303) 530-4333; or Dan 
Schweikert, Cadence Design Systems, 555 
River Oaks Pkwy., Bldg. 4, San Jose, CA 


Sixth Int’l Workshop on Scientific 
viz and Statistical Database Manage¬ 
ment, June 9-11, Zurich, Switzerland. Co¬ 
sponsor: ACM SIGMOD. Contact H. 
Hinterberger, Inst, for Scientific Comput¬ 
ing, ETH Zentrum, CH-8093 Zurich, Swit¬ 
zerland, phone 41 (1) 254-7436, fax 41 (1) 
262-3973. 

IEA/AIE 92, Fifth Int’l Conf. on In- 
vAz dustrial and Eng. Applications of Ar¬ 
tificial Intelligence and Expert Systems, 
June 9-12, Paderborn, Germany. Cospon¬ 
sors: Univ. of Paderborn et al. Contact 
Moonis Ali, Univ. of Tennessee Space 
Inst., MS 15, Tullahoma, TN 37388-8897, 
phone (615) 455-0631, ext. 283, e-mail 
alif@udsivl.bitnet; or Fevzi Belli, Univ. of 
Paderborn, Postfash 1621, 4790 Paderborn, 
Germany, phone 49 (5251) 60-3282, fax 49 
(5251) 602-519, e-mail belli@adt. 
uni-paderborn. de. 

(gfa 1CDCS 92,12th Int’l Conf. on Dis- 
vAz tributed Computing Systems, June 9- 

12, Yokohama, Japan. Cosponsor: Infor¬ 
mation Processing Soc. of Japan. Contact 
Ming T. (Mike) Liu, Computer and Infor¬ 
mation Science Dept., Ohio State Univ., 
2036 Neil Ave., Columbus, OH 43210- 
1277, phone (614) 292-6552, fax (614) 292- 
9021, e-mail mike.liu@osu.edu; or Yutaka 
Matsushita, Instrumentation Eng. Dept., 
Keio Univ., 3-14-1 Hiyoshi, Kohoku-ku, 
Yokohama, Japan 223, phone 81 (045) 563- 
1141 ext. 3564, fax 81 (045) 562-7625, 
e-mail on@inst.keio.ac.jp. 

ITS 92, Second Int'l Conf. on Intelli- 
vAz gent Tutoring Systems, June 10-12, 

Montreal. Cosponsors: Univ. of Montreal 
et al. Contact Claude Frasson, Departe- 
ment d’lRO, Universite de Montreal, CP 
6128 Succ A. Montreal, Que., Canada H3C 
3J7, phone (514) 343-7019, fax (514) 343- 
5834, e-mail frasson@iro.umontreal.ca. 

CBMS 92, IEEE Symp. on Comput- 
vAz er-Based Medical Systems, June 14- 

17, Durham, N.C. Cosponsors: IEEE Com¬ 
puter Soc., IEEE Eastern North Carolina 
Section, Eng. in Medicine and Biology Soc. 
Contact James N. Brown, Jr., Research 
Triangle Inst., PO Box 12194, Research 
Triangle Park, NC 27709, phone (919) 541- 
6975, fax (919) 541-5945; or Peter Santago, 
Radiology Dept., Bowman Gray School of 
Medicine, Medical Center Blvd., Winston- 
Salem, NC 27157-1022, phone (919) 748- 
4260, fax (919) 748-2870, e-mail cbms@ 
mrips.bgsm.wfu.edu. 

NECC 92,13th Nat’l Educational 
vAz Computing Conf., June 15-17, Dal¬ 
las. Contact Cathy Norris, Computer Edu¬ 
cation and Cognitive Systems, Univ. of 
North Texas, PO Box 5155, UNT Station, 
Denton, TX 76203, phone (817) 565-2824, 
fax (817) 565-4425. 

tglji ICSI 92, Second Int’l Conf. on Sys- 
vAz terns Integration, June 15-18, Morris¬ 
town, NJ. Cosponsors: New Jersey Inst, of 
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Tech. Computer and Information Science 
Dept., ACM et al. Contact Peter A. Ng, 
Computer and Information Science Dept., 
NJIT, University Heights, Newark, NJ 
07102, phone (201) 596-3387, e-mail ng_p@ 
vienna.njit.edu; or C.V. Ramamoorthy, 
Univ. of California, EECS Dept., Berke¬ 
ley, CA 94720, phone (415) 642-4751, fax 
(415)642-5775. 


^ CVPR 92, IEEE Computer Society 
' Conf. on Computer Vision and Pat¬ 


tern Recognition, June 15-18, Champaign, 
Ill. Contact A. Rosenfeld, Center for Au¬ 
tomation Research, Univ. of Maryland. 
College Park, MD 20742, e-mail ar@alv. 
umd.edu. 


Parle 92, Parallel Architectures and 
Languages Europe, June 15-18, Par¬ 
is. Cosponsors: IEEE Region 8 et al. Con¬ 
tact Daniel Etiemble, LR1, Bat 490, Univ. 
of Paris Sud, 91405 Orsay Cedex, France, 
phone 33 (1) 6941-6621, fax 33 (1) 6941- 
6586, e-mail de@lri.lri.fr. 

Compass 92, Seventh Conf. on Computer 
Assurance, June 15-18, Gaithersburg, Md. 
Cosponsors: IEEE, IEEE Aerospace and 
Electronic Systems Soc. Contact Robert 
Ayers, ARINC Research, 2551 Riva Rd., 
Annapolis, MD 21401, phone (301) 266- 
4741, fax (301) 266-4040. 


OTM Computer Security Foundations 

Workshop V, June 16-18, Franconia, 
N.H. Contact Leonard LaPadula, Informa¬ 
tion Security Technical Center, Mitre 
Corp., Bedford, MA 01730-0208, phone 
(617) 271-3261, e-mail ljl@mitre.org; or 
Ravi Sandhu, ISSE Dept., George Mason 
Univ., Fairfax, VA 22030-4444, phone 
(703) 993-1659. e-mail sandhu@sitevax. 
gmu.edu. 

SEKE 92, Fourth Int’l Conf. on Soft- 
vU' ware Eng. and Knowledge Eng., 

June 17-19, Capri, Italy. Cosponsors: Univ. 
of Salerno et al. Contact Shi-Kuo Chang, 
Computer Science Dept., Univ. of Pitts¬ 
burgh, Pittsburgh, PA 15260, phone (412) 
624-8493; or Genoveffa Tortora, Diparti- 
mento di Informatica ed Applicazioni, 
Univ. di Salerno, 1-84081 Baronissi, Saler¬ 
no. Italy, phone 39 (89) 822-333. fax 39 
(81) 482-745, e-mail jentor@udsab.dia. 
unisa.it or usditort@inacriai.bitnet. 


CTEl Int’l Workshop on Hardware Fault- 
^35' Tolerance in Multiprocessors, June 
22-23, Amherst, Mass. Sponsor: IEEE 
Computer Soc. Technical Committee on 
Fault-Tolerant Computing. Contact 
Donald S. Fussell, Computer Science 
Dept., TAY 2.124, Univ. of Texas at Aus¬ 
tin, Austin, TX 78712-1188, phone (512) 
471-9719, fax (512) 471-7028, e-mail 
fussell@cs.utexas.edu. 


Computer and Information Science, Syra¬ 
cuse Univ., Syracuse, NY 13244, fax (315) 
443-1954, e-mail royer@top.cis.syr.edu. 

LICS, Seventh IEEE Symp. on Logic 
vU' in Computer Science, June 22-25, 

Santa Cruz, Calif. Sponsor: IEEE Comput¬ 
er Soc. Technical Committee on Mathe¬ 
matical Foundations in Computing. Con¬ 
tact Robert L. Constable, Computer 
Science Dept., Cornell Univ., 4149 Upson, 
Ithaca, NY 14853, phone (607) 255-9204, 
fax (607) 255-4428. 

CGI 92, Computer Graphics Int’l 

Conf., June 22-26, Tokyo. Cospon¬ 
sors: Computer Graphics Soc. et al. Con¬ 
tact R.A. Eamshaw, Computer Graphics, 
Univ. of Leeds, Leeds LS2 9JT, England, 
phone 44 (532) 335-414, fax 44 (532) 336- 
017; or Toki Takahashi, Autonomous Ro¬ 
bot Systems Lab, NTT Human Interface 
Labs, 3-9-11 Midori-cho, Musashino-shi, 
Tokyo 180, Japan, phone 81 (422) 59-2406, 
fax 81 (422) 59-2245, e-mail cgi92@nttarm. 
ntt.jp (Internet). 

RSP, Third Int’l Workshop on Rapid 

System Prototyping, June 23-25, Re¬ 
search Triangle Park, N.C. Cosponsors: 
IEEE Computer Soc. Technical Commit¬ 
tees on Design Automation, Simulation, 
and Test Tech. Contact Nick Kanopoulos, 
Center for Systems Eng., Research Trian¬ 
gle Inst., 3040 Cornwallis Rd., Research 
Triangle Park, NC 27709, phone (919) 541- 
7341, fax (919) 541-6515, e-mail rsp@rti.rti. 
org. 

(fft) 10th Software Reliability Symp., 
nU' June 25-26, Denver. Sponsor: IEEE 
Reliability Soc. Denver Chapter. Contact 
Rich Karcich, Storage Tech. Corp., 2270 S. 
88th St., MS 2286, Louisville, CO 80028- 
5319, phone (303) 673-6223, fax (303) 673- 
3353. 


July 1992 


IEEE Intelligent Vehicles 92, July 1-2, 

Michigan. Sponsor: IEEE Industrial Elec¬ 
tronics Soc. Contact Ichiro Masaki, Com¬ 
puter Science Dept., GM Research Labs, 
30500 Mound Rd., Warren, MI 48090-9055, 
phone (313) 986-1466, fax (313) 986-9356, 
e-mail masaki@gmr.com. 


1992 Workshop on Fault-Tolerant 
Parallel and Distributed Systems, 
July 6-7, Amherst, Mass. Cosponsor: Univ. 
of Massachusetts at Amherst. Contact 
Donald S. Fussell, Computer Science 
Dept., Univ. of Texas at Austin, TAY 
2.124, Austin, TX 78712-1188, phone (512) 
471-9719, fax (512) 471-7028, e-mail 
fussell@cs.utexas.edu. 


Seventh IEEE Conf. on Structure in 
Complexity Theory, June 22-25, Bos¬ 
ton. Sponsor: IEEE Computer Soc. Tech¬ 
nical Committee for Math. Foundations of 
Computing. Contact J. Royer, School of 


CASE 92, Fifth Int’l Workshop on 
Computer-Aided Software Eng., July 
6-10, Montreal. Contact Gene Forte, 

CASE Outlook, 11830 Kerr Pkwy. #315, 
Lake Oswego, OR 97035, phone (503) 245- 


6880, fax (503) 245-6935, e-mail g.forte@ 
compmail.com: Nazim Madhavji, School of 
Computer Science, McGill Univ., 3480 
University St., Montreal, Que., Canada 
H3A 2A7, phone (514) 398-3740, fax (514) 
398-3883, e-mail case@softeng.cs.mcgill.ca; 
or John Jenkins, City Univ. of London, 
Business Systems Analysis Dept., London, 
UK, fax 44 (71) 608-1270. 

Iros 92, Fifth Int’l Conf. on Intelligent Ro¬ 
bots and Systems, July 7-10, Raleigh, N.C. 
Cosponsors: IEEE Industrial Electronics 
Soc., Robotics Soc. of Japan et al. Contact 
Avi Kak, School of Electrical Eng., Purdue 
Univ., West Lafayette, IN 47907, phone 
(317) 494-3551, fax (317) 494-6440, e-mail 
kak@ecn.purdue.edu; or Kazuo Tanie, Me¬ 
chanical Eng. Lab, MITI, 1-2 Namiki, 
Tsukuba-shi, Ibaraki-ken, 305, Japan, 
phone 81 (298) 54-2656, fax 81 (298) 54- 
2518, e-mail ml750@mel.go.jp. 

FTCS 22, 22nd Int’l Symp. on Fault- 
'S' Tolerant Computing. July 8-10, Bos¬ 
ton. Cosponsor: Univ. of Massachusetts at 
Amherst. Contact Dhiraj K. Pradhan, 
Electrical and Computer Eng. Dept., Univ. 
of Massachusetts at Amherst, Amherst, 

MA 01003, phone (413) 545-0160, fax (413) 
545-4611, e-mail pradhan@ecs.umass.edu. 


August 1992 

rijfji) 17th Congress Workshop, Aug. 2-14, 

Washington, DC. Sponsor: United 
Nations. Contact Lawrence W. Fritz, GE 
Aerospace, PO Box 8048-10A26, Philadel¬ 
phia, PA 19101, phone (215) 531-3205, fax 
(215) 962-3698. 

ASAP 92, Int’l Conf. on Application- 
N*?' Specific Array Processors, Aug. 4-7, 

Berkeley, Calif. Sponsor: Univ. of Califor¬ 
nia at Berkeley. Contact Jose Fortes, 
School of Electrical Eng., Purdue Univ., 
West Lafayette, IN 47907, phone (317) 
494-3646, fax (317) 494-6440, e-mail 
fortes@ecn.purdue.edu; or Mary Stewart, 
EECS Dept., Cory Hall, Univ. of Califor¬ 
nia, Berkeley, CA 94720. 

Hot Chips IV, Symp. on High-Per- 
N5?' formance Chips, Aug. 9-11, Stanford, 
Calif. Sponsor: IEEE Computer Soc. Tech¬ 
nical Committee on Microprocessors and 
Microcomputers. Contact Glen Langdon, 
phone (408) 459-2212, e-mail langdon@cse. 
ucsc.edu. 

Crypto 92, Aug. 16-20, Santa Bar- 
vU' bara, Calif. Sponsor: Int’l Assoc, of 
Cryptologic Research. Contact Spyros S. 
Magliveras, Computer Science and Eng. 
Dept., Univ. of Nebraska, Lincoln, NE 
68588-0115, phone (402) 472-5005, fax 
(402) 472-7767, e-mail spyros@helios.unl. 
edu. 


Rh Int’l Workshop on Distributed Data 
Management, Aug. 19-21, Edmon- 
i, Alta., Canada. Cosponsors: Canadian 
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Information Processing Soc. et al. Contact 
M. Tamer Ozsu, Computing Science Dept., 
Univ. of Alberta, Edmonton, Alta., Cana¬ 
da T6G 2H1, phone (403) 492-1071, fax 
(403) 492-1071. 


VLDB 92,18th Int’l Conf. on Very 
vi? Large Data Bases, Aug. 23-27, Van¬ 
couver, B.C., Canada. Cosponsors: VLDB 
Endowment, Canadian Information Pro¬ 
cessing Soc. et al. Contact Paul Sorenson, 
Computer Science Dept., Univ. of Alberta, 
Edmonton, Alta.. Canada T6G 2H1, phone 
(403) 492-4589, fax (403) 492-1071, e-mail 
vldb92@cs.ualberta.ca or sorenson@cs. 
ualberta.ca. 


Int’l Workshop on Hardware-Soft- 
V5? ware Codesign, Aug. 31-Sept. 2, Es¬ 
tes Park, Colo. Cosponsors: ACM et al. 
Contact Joanne E. Degroat, Ohio State 
Univ., 205 Neil Ave., Columbus, OH 
43210, phone (614) 292-2439, e-mail 
degroat@ee. eng.ohio-state.edu. 


September 1992 


Euro DAC 92, European Design Au- 
tomation Conf., Sept. 7-10, Ham¬ 
burg, Germany. Cosponsors: IEEE Circuit 
and Systems Soc. et al. Contact A. Zylber- 
sztejn. Bull SA, 121 Ave. De Malakoff, 
75116 Paris, France, phone 33 (14) 502- 
9583, fax 33 (14) 502-9307. 


Congress 92,12th World Computer Con¬ 
gress, Sept. 7-11, Madrid. Sponsor: Int'l 
Federation for Information Processing. 
Contact Grupo Geyseco, Congress 92, 
Mauricio Legendre, 4-8.° G., E-28046 
Madrid, Spain, fax 34 (1) 323-4936, e-mail 
ifip92@dit.upm.es. 

ICIP 92, Second Singapore Int’l Conf. on 
Image Processing, Sept. 7-11, Singapore. 
Cosponsors: IEEE Singapore Section et al. 
Contact Technical Programme Chair, ICIP 
92, IEEE Singapore Section, 200 Jalan Sul¬ 
tan, #11-03 Textile Centre, Singapore 0719, 
phone (65) 291-9690, fax (65) 292-8596. 

HPDC, First Int’l Workshop on High- 
Performance Distributed Comput¬ 
ing, Sept. 9-10, Syracuse, N.Y. Cosponsor: 
Syracuse Univ. Contact Geoffrey C. Fox, 
NPAC, Rm. 3-131, 111 College PL, Syra¬ 
cuse, NY 13244-4100, phone (315) 443- 
4741, fax (315) 443-1973. 

Fifth Digital Signal Processing Workshop, 
Sept. 13-16, Starved Rock State Park, Ill. 
Sponsor: IEEE Signal Processing Soc. 
Contact Mark J.T. Smith, School of Elec¬ 
trical Eng., Georgia Inst, of Tech., Atlanta, 
GA 30332-0250, phone (404) 894-6291. 


SESS, Software Eng. Standards 
Symp., Sept. 13-17, Brighton, UK. 
Contact Takis Katsoulakos, Lloyd’s Regis¬ 
ter, Lloyd’s Register House, 29 Wellesley 
Rd„ Croydon. CRO 2AJ, UK, phone (081) 
681-4774. 


Engineering Design 
Opportunities in 
Burlington, Vermont 


One of the world’s most advanced semiconductor operations is what 
you’ll find at IBM’s major development and manufacturing facility in 
Burlington, where continued business growth is matched by a superb 
living environment. We now have outstanding career opportunities for 
engineers with the specialized computer skills to make significant impact 
on RISC microprocessor development. 

Logic Design 

Responsible for definition, logic design and verification of high perfor¬ 
mance RISC microprocessors. To qualify, you must possess a BSEE or 
higher, with an emphasis on Computer Engineering, and be capable of 
carrying logic design through to physical chip design stage. Minimum of 
3 years in logic/chip, CMOS and VLSI design required. RISC experience 
is key. Background in microprocessor and multiprocessor design desirable. 

Circuit Design 

Will design CMOS circuitry for RISC-based microprocessor functions. 
Includes custom SRAM cache design, complex logic dataflow circuitry, 
random logic, 10, clocking and other circuitry in custom microprocessor 
layouts.Requires BSEE or higher with emphasis on Computer Engineer¬ 
ing or Circuit Design. Ability to design complex CMOS or Bi CMOS 
circuits and perform circuit analysis and verification is essential, along 
with minimum of 3 years circuit design experience in industry. CMOS, 
VLSI, digital circuit design is a prerequisite. 

Physical Design 

Responsible for CMOS VLSI chip physical design of RISC microproces¬ 
sor in advanced CMOS technology. Includes using state-of-the-art CAD 
tools to perform chip layout, wiring and chip timing analysis. A BSEE or 
higher, with emphasis on Computer Engineering or Circuit Design, is 
essential, along with at least 3 years of physical design experience in 
industry. RISC and CMOS, VLSI design experience (chip layout/wiring) 
necessary. Background in microprocessor design desirable. 

Design Verification & Test 

Will develop verification programs and behaviorals to verify RISC micro¬ 
processor functions, and perform failure analysis at system and chip 
level. Will also develop test programs and fault models which insure the 
manufacturing testability and quality levels of custom designed RISC 
microprocessors. Must possess a BSEE/CS or higher with emphasis on 
Computer Engineering or Programming, and at leasts years in verifica¬ 
tion/test of RISC microprocessors. Computer (RISC) architecture and 
microprocessor design knowledge essential, along with proficiency in C 
and Assembly Language Programming. Microprocessor design experi¬ 
ence desirable. 


Located between Lake Champlain and Vermont’s Green Mountains, 
Burlington offers year round recreation and open space. Unspoiled 
beauty, affordable housing and a sense of community come together 
here. This is life at its most enjoyable; technology at its best. 

IBM offers salaries commensurate with qualifications and a comprehen¬ 
sive benefit package. For confidential consideration, please send your 
resume, indicating area of interest, to: IBM Corporation, Professional 
Recruiting, 1000 River Street, Essex Junction, VT 05452. 


An equal opportunity employer. 


March 1992 

















MTO DCCA 3, Third Working Conf. on 

Dependable Computing for Critical 
Applications, Sept. 14-16, Mondello, Italy. 
Sponsor: Int’l Federation for Information 
Processing Working Group 10.4. Contact 
Carl E. Landwehr, Code 5540, Naval Re¬ 
search Lab, Washington, DC 20375-5000, 
phone (202) 767-3381, fax (202) 404-7942; 
or Luca Simoncini, Dipartimento di Ingeg- 
neria dell’Informazione, Univ. of Pisa, Via 
Diotisalvi 2, 56100 Pisa, Italy, phone 39 
(50) 593-443 or 550-100, fax 39 (50) 554- 
342, e-mail simon@icnucevm.cnuce.cnr.it, 

ICARCV 92, Second Int’l Conf. on 

Automation, Robotics, and Comput¬ 
er Vision, Sept. 15-18, Singapore. Cospon¬ 
sors: Singapore Institution of Engineers 
et al. Contact ICARCV Secretariat, Asso¬ 
ciated Conventions and Exhibitions, 204 
Bukit Timah Rd., #04-00, Boon Liew 
Bldg., Singapore 0922, phone (65) 799- 
5470, fax (65) 791-2687, e-mail emital@ 
ntuvax.bitnet. 

WLI, IEEE Conf. on Wireless LAN 
vS?' Implementation, Sept. 17-18, Day- 
ton, Ohio. Contact James T. Geier, 685 N. 
Enon Rd., Yellow Springs, OH 45387, 
phone (513) 255-6224. 

ITC 92,1992 Int’l Test Conf., Sept. 

20-24, Baltimore. Cosponsor: IEEE 
Philadelphia Section. Contact Doris Tho¬ 
mas,.514 Pleasant Valley Blvd., Suite 3, Al¬ 
toona, PA 16602, phone (814) 941-4666, 
fax (814) 941-4668. 

(jjfi) ASIC 92, Fifth IEEE Int’l Conf. on 

Application-Specific Integrated Cir¬ 
cuits, Sept. 21-25, Rochester, N.Y. Spon¬ 
sor: IEEE Rochester Section. Contact 
Lynne M. Engelbrecht, 170 Mt. Read 
Blvd., Rochester, NY 14611, phone (716) 
328-2310, fax (716) 436-9370; or Y. Tim 
Tsia, Eastman Kodak, MC-02015,1669 
Lake Ave., Bldg. 81.454/KRL, Rochester, 
NY 14650-2015, phone (716) 722-4896, fax 
(716) 722-9053. 

Compsac 92, 16th Int’l Computer 
vi?' Software and Applications Conf., 
Sept. 22-25, Chicago. Contact Stephen 
Yau, Univ. of Florida, CIS Dept., Rm. 301, 
Gainesville, FL 32611, phone (904) 335-8006. 

PRICAI, Second Pacific Rim Int’l 
^=7 Conf. on Artificial Intelligence, Sept. 
23-25, Sungdong-ku, Korea. Cosponsors: 
Korea Information Science Soc. et al. Con¬ 
tact Jim Hyung Kim, Korea Advanced 
Inst, for Science and Tech., Center for Ar¬ 
tificial Intelligence Research, 373-1 Ku- 
song-dong, Yusong-ku, Taejon, 305-701, 
Korea, phone 82 (42) 829-3517, fax 82 (42) 
829-8700, e-mail jkim@cair,kaist.ac.kr. 

® Graphicon, Computer Graphics in 
Science and Arts, Sept. 28-Oct. 30, 

Moscow, Russia. Cosponsor: ACM. Con¬ 
tact Yury Golubev, Keldysh Inst, of Ap¬ 
plied Math, Miusskaya Sq. 4, Moscow 
125047, Russia, phone (095) 250-7817. 

13th Int’l Symp. on Electronics Manufac¬ 
turing Tech., Sept. 28-30, Baltimore. Co¬ 


sponsors: IEEE Components, Hybrids, and 
Manufacturing Tech. Soc., Electronic In¬ 
dustries Assoc. Contact Bill Moody, 2529 
Eaton Rd., Wilmington, DE 19810, phone 
(302) 478-4143, fax (302) 478-7057. 

Int’l Workshop on Hardware-Soft- 

ware Codesign, Sept. 30-Oct. 2, Estes 
Park, Colo. Cosponsors: IEEE Computer 
Soc., IEEE Circuits and Systems Soc. Con¬ 
tact Joanne E. DeGroat, Ohio State Univ., 
205 Dreese Lab, 205 Neil Ave., Columbus, 
OH 43210, phone (614) 292-2439, e-mail 
degroat@ee.eng.ohio-state.edu; or Alfred 
E. Dunlop, AT&T Bell Labs, 600 Moun¬ 
tain Ave., Murray Hill, NJ 07974, phone 
(908) 582-6570, e-mail aed@allegra.att. 


October 1992 


CTM Second Int’l Workshop on Respon- 

sive Computer Systems, Oct. 1-2, 

Saitama, Japan. Sponsor: US Office of Na¬ 
val Research. Contact Miroslaw Malek, 
Electrical and Computer Eng. Dept., Univ. 
of Texas, Austin, TX 78712, phone (512) 
471-5704, fax (512) 471-0954, e-mail 
malek@emx.utexas.edu; or Tohru Kikuno, 
Information and Computer Science Dept., 
Osaka Univ., 1-1, Machikaneyama-cho, 
Toyonaka-shi, Osaka, 560, Japan, phone 81 
(6) 844-1151, fax 81 (6) 841-9741, e-mail 
kikuno@ics.osaka-u.ac.jp. 

Sixth Software Eng. Inst. Conf. on 

Software Eng. Education, Oct. 5-6, 
and 11th SEI Educator Development 
Workshop, Oct. 7, San Diego, Calif. Co- 
sponsor: Software Eng. Inst. Contact Carol 
Sledge, SEI, Carnegie Mellon Univ., Rm. 
4206, Pittsburgh, PA 15213-3890, phone 
(412) 268-7708, fax (412) 268-5758, e-mail 
cas@sei.cmu.edu. 

11th Symp. on Reliable Distributed 

Systems, Oct. 5-7, Houston. Cospon¬ 
sors: IEEE Computer Soc. Technical Com¬ 
mittee on Distributed Processing et al. 
Contact Thomas F. Lawrence, Rome Lab/ 
C3AB, Bldg. 3, Griffiss Air Force Base, 

NY 13441, phone (315) 330-2158, fax (315) 
330-3911; or Kishor S. Trivedi, Electrical 
Eng. Dept., Duke Univ., Durham, NC 
27706, phone (919) 660-5269, e-mail kst@ 
egr.duke.edu. 

/£fj\ ISSRE 92, Third Int’l Symp. on Soft- 

ware Reliability Eng., Oct. 7-9, Re¬ 
search Triangle Park, N.C. Cosponsors: 
IEEE Computer Soc. Technical Commit¬ 
tee on Software Eng. et al. Contact Mladen 
A. Vouk, Computer Science Dept., Box 
8206, North Carolina State Univ., Raleigh, 
NC 27695-8206, phone (919) 515-7886, fax 
(919) 515-5839, e-mail vouk@adm.csc.ncsu. 


yKI 17th Conf. on Local Computer Net- 
works, Oct. 11-14, Minneapolis. 
Sponsor: IEEE Computer SoC. Technical 
Committee on Computer Comm. Contact 


Steve Bell, Hughes LAN Systems, MS 392, 
1072 S. Saratoga Svale Rd., San Jose, CA 
95129, phone (415) 966-7926, fax (415) 
966-7990, e-mail sbell@hls.com. 

Milcoin 92, Oct. 11-14, San Diego, Calif. 
Cosponsors: IEEE Comm. Soc. et al. Con¬ 
tact Milcom 92, General Dynamics Elec¬ 
tronics Div., PO Box 85106, San Diego, 

CA 92186-5106; Security Dept. MZ 7101- 
G, Milcom 92, General Dynamics Elec¬ 
tronics Div., PO Box 85227, San Diego, 

CA 92186-5227; or Dennis E. Litchfield, 
Office of the Assistant Secretary of De¬ 
fense (C 3 I), The Pentagon, Rm. 3D 228, 
Washington, DC 30301-3040. 

® ICCD 92, Int’l Conf. on Computer 
Design, Oct. 12-14, Cambridge, 

Mass. Cosponsor: IEEE Circuit and Sys¬ 
tems Soc. Contact IEEE Computer Soc., 
1730 Massachusetts Ave. NW, Washington, 
DC 20036-1903, phone (202) 371-1013, fax 
(202) 728-0884. 

ASPLOS 5, Fifth Conf. on Architec- 
tural Support for Programming Lan¬ 
guages and Operating Systems, Oct. 12-15, 

Boston. Sponsor: ACM. Contact Barry 
Flahive, Hewlett-Packard, Apollo Systems 
Div., 300 Apollo Dr., MS CHR 02 DE, 
Chelmsford, MA 01824, phone (508) 256- 
2471 or 6600, e-mail flahive@apollo.hp. com. 

Seventh Int’l Software Process 
v!?' Workshop, Oct. 15-18, Yountville, 
Calif. Sponsor: Rocky Mountain Inst, of 
Software Eng. Contact Ian Thomas, Soft¬ 
ware Design and Analysis, 444 Castro St., 
Suite 413, Mountain View, CA 94041, 
phone (415) 694-1464 

OOPSLA 92, Seventh Conf. on Object- 
Oriented Programming Systems, Languag¬ 
es, and Applications, Oct. 18-22, Vancou¬ 
ver, B.C., Canada. Sponsor: ACM. Contact 
John Pugh, School of Computer Science, 
Carleton Univ., Colonel By Drive, Ottawa, 
Ont., Canada K1S 5B6, phone (613) 788- 
4330, e-mail oopsla92@carleton.ca. 

Frontiers 92, Fourth Symp. on the 
Frontiers of Massively Parallel Com¬ 
putation, Oct. 19-21, McLean, Va. Cospon¬ 
sors: NASA Goddard Space Flight Center 
et al. Contact Pearl Wang, Computer Sci¬ 
ence Dept., George Mason Univ., 440 Uni¬ 
versity Dr.. Fairfax, VA 22030-4444, phone 
(703) 993-1527, fax (703) 993-1521. 

10th Pacific Northwest Software Quality 
Conf., Oct. 19-21, Portland, Ore. Contact 
Hilly Alexander, ADP Dealer Services 
Group, 2525 SW First Ave.. Portland, OR 
97201-4760, phone (503) 294-4200. 

Visualization 92, Oct. 19-23, Boston. 
Sponsor: IEEE Computer Soc. Tech¬ 
nical Committee on Computer Graphics. 
Contact Bruce E. Brown, Oracle, 500 Ora¬ 
cle Pkwv.. Box 659412, Redwood Shores, 
CA 94065, phone (415) 506-6202, fax (415) 
726-0983; or Gregory M. Nielson, Arizona 
State Univ.. Rural Rd. and University 
Ave., Tempe, AZ 85287-5406, phone (602) 
965-2785, e-mail nielson@enuxva.eas.asu.edu. 
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CALL FOR PAPERS 


Third International Workshop on Research Issues on Data Engineering: 

INTEROPERABILITY IN MULTIDATABASE SYSTEMS 
Vienna, Austria, April 18-20, 1993 

Co-sponsored by the IEEE Computer Society and the Austrian Computer Society 


© ♦ 


RIDE-IMS’93 is the third of a series of annual workshops on Research Issues in Data Engineering (RIDE). RIDE work¬ 
shops are held in conjunction with the IEEE CS International Conferences on Data Engineering. Following the successful 
RIDE-IMS’91 held in Kyoto, Japan, the next RIDE workshop will also focus on interoperability of heterogeneous and 
autonomous database and knowledge systems. 


TOPICS: We solicit papers describing original ideas and new results on the foundations of interoperability in systems 
that support global applications accessing multiple database and/or knowledge systems. The papers should address the 
problems of autonomy and heterogeneity of the member systems. Suggested topics include but are not limited to: 


• Autonomy, heterogeneity, authorization and security 

• Semantic issues 

• Schema analysis and integration 

• Interdatabase dependencies 

• Consistency and Recovery 


• Multidatabase and transaction specification languages 

• Tools for building federated/multi-DBMS systems 

• Queries and updates 

• Applications (e.g., GIS, CIM) 

• Interoperability with software systems 


We also encourage industrial submissions of papers discussing product/prototype development or application experience. 


WORKSHOP GENERAL CO-CHAIRS: 


STEERING COMMITTEE: 


Elisa Bertino 
Dip. di Matematica 
Universita' di Genova 
Tel.: +39-10-353-8034 

Email: bertino@icnucevm.cnuce.cnr.it 


Susan Urban 

Computer Science Department 
Arizona State University 
Tel.: +1-602-965-2784 

Email: urban@asuvax.eas.asu.edu 


Ahmed Elmagarmid, co-chair (USA) 
Joseph Urban, co-chair (USA) 
Yahiko Kambayashi (Japan) 

Marek Rusinkiewicz (USA) 


INSTRUCTIONS: Authors are invited to submit six copies of papers, no more than 20 pages (one and half or double¬ 
spaced) before July 15, 1992, to the appropriate PROGRAM CHAIR. Longer papers may not be reviewed. 


Europe & Africa America, Asia & Australia 

Hans-J. Schek Amit Sheth 

Department of Computer Science Bellcore, RRC 1J-210 

' Swiss Federal Institute of Technology 444 Hoes Lane 

ETH Zentrum, CH-8092 Zurich, Switzerland Piscataway, NJ 08854-4182, USA 
| Tel.: +41-1-254-7240 Tel.: +1-908-699-3300 

i Fax: +41-1-262-3973 Fax: +1-908-336-2969 

Email: schek@inf.ethz.ch Email: amit@ctt.bellcore.com 

Selection will be based on originality and contribution to the field. The proceedings consisting of the accepted papers will 
be published and distributed to the participants. 


IMPORTANT DATES: 

Deadline for submission: 
July 15, 1992 

Notification of acceptance or 
rejection: November 1, 1992 
Final camera-ready due: 
January 1, 1993 


PROGRAM COMMITTEE (partial list): _ 

Georges Gardarin (France) 


Raphael Alonso (USA) 

Peter Apers (Netherlands) 

Yuri Breitbart (USA) 

Phil Cannata (USA) 

Wolfgang Effelsberg (Germany) 
Ahmed Elmagarmid (USA) 
Tetsnya Furukawa (Japan) 


Sandy Heiler (USA) 

David Hsiao (USA) 

Leonid Kalinichenko (Russia) 
Wolfgang Klaus (Germany) 
Eva Kuhn (Austria) 

Witold Litwin (USA) 


Yoshifumi Masunaga (Japan) 
Dennis McLeod (USA) 

M. Tamer Ozsu (Canada) 
Sudha Ram (USA) 

Marek Rusinkiewicz (USA) 
Ron Sacks-Davis (Australia) 
Felix Saltor (Spain) 


Peter Scheuermann (USA) 
Gunter Schlageter (Germany) 
Ming Shan (USA) 

Avi Silberschatz (USA) 

Letizia Tanca (Italy) 

Gerhard Weikum (Switzerland) 
Antoni Wolski (Finland) 


Local arrangements: Eva Kuhn & Gerti Kappel (Austria) 
European ind. coordinator: Christoph Freytag (Germany) 
CEC coordinator: Janis Folkmanis (pending for approval) 
Publicity chair: Dimitrios Georgakopoulos (USA) 
Registration chair: Jim Geller (USA) 


US ind. coordinator: Gomer Thomas (USA) 
Asian coordinator: Yahiko Kambayashi (Japan) 
Financial chair: Patrick Bobbie (USA) 
Publication chair: Bogdan Czejdo (USA) 















Preliminary Program 

1992 IEEE Symposium on 

RESEARCH IN SECURITY and PRIVACY 

May 4-6,1992 • The Claremont Resort • Oakland, California 


Sunday, May 3 

4:00-6:30 pm Registration materials 
available; Reception 

Monday, May 4 

8:45-9:00 am 
Welcoming Remarks: 

Deborah Cooper, John McLean 

9:00-10:30 am 
Distributed Systems: 

John Rushby, Session Chair 

• On Inter-Realm Authentication in Large 
Distributed Systems, Virgil Gligor, Shyh- 
Wei Luan, Joseph Palo 

• Integrating Security in a Group Oriented 
Distributed System, Michael Reiter, Kenneth 
Birman, Li Gong 

• Authorization in Distributed Systems: A 
Formal Approach, Thomas Woo, Simon Lam 

10:30-11:00 am Break 

11:00-12:00 noon 
Covert Channels: 

Tom Berson, Session Chair 

• Lattice Scheduling and Covert Channels, 
Wei-MingHu 

• The Influence of Delay Upon an Idealized 
Channel's Bandwidth, Ira Moskowitz, Allen 
Miller 


Tuesday, May 5 

9:00-10:30 am 

Security Models: 

George Dinolt, Session Chair 

• The Typed Access Matrix Model, Ravi 
Sandhu 

• A Resource Allocation Model for Denial 
of Service, Jonathan Millen 

• Non-Monotonic Transformation of Access 
Rights, Ravi Sandhu, Gurpreet Suri 

10:30-11:00 am Break 

11:00-12:00 noon 

Information Flow: 

Dale Johnson, Session Chair 

• A Logical Approach to Multilevel 
Security of Probabilistic Systems, James 
Gray, Paul Syverson 

• Using Traces of Procedure Calls to Reason 
About Composability, Catherine Meadows 

12:00-2:00 pm Lunch 

2:00-3:00 pm 

Integrity: 

Richard Kemmerer, Session Chair 

• Panel: Report of an Integrity Working 
Group, Panelists: Marshall Abrams, Edward 
Amoroso, Leonard LaPadula, Teresa Lunt, 
James Williams 

3:00-3:30 pm Break 


Wednesday, May 6 

9:00-10:30 am 

Systems: 

Tanya Korelsky, Session Chair 

• Evolution of a Trusted B3 Window 
System Prototype, Jeremy Epstein, John 
McHugh, Rita Pascale, Charles Martin, 
Douglas Rothnie, Hilarie Orman, Ann 
Marmor-Squires, Martha Brandstad, Bonnie 
Danner 

• A Neural Network Component for an 
Intrusion Detection System, Herve Debar, 
Monique Becker, Didier Siboni 

• An Optimal Solution to the Secure Reader 
Writer Problem, Glenn Benson 

10:30-11:00 am Break 

11:00-12:00 noon 

Database Security: 

John Dobson, Session Chair 

• Security for Object-Oriented Database 
Systems, Jonathan Millen, Teresa Lunt 

• A Natural Decomposition of Multi-level 
Relations, Frederic Cuppens, Kioumars 
Yazdanian 

12:00-12:15 pm Presentation of 

Symposium Awards 

12:15 pm Symposium Adjourns 

12:15-2:00 pm Lunch 


12:00-2:00 pm Lunch 

2:00-3:00 pm 
Invited Speaker: 

John McLean, Session Chair 
Speaker and Title to be announced 

3:00-3:30 pm Break 
3:30-5:00 pm 

Cryptographic Protocols: 

Dan Nessett, Session Chair 

• Encrypted Key Exchange: Password- 
Based Protocols Secure Against Dictionary 
Attacks, Steven Bellovin, Michael Merritt 

• On Message Integrity in Cryptographic 
Protocols, Stuart Stubblebine, Virgil Gligor 

• Roles in Cryptographic Protocols, Einar 
Snekkenes 

5:30-7:30 pm Reception 
5:00 pm Poster Sessions 


3:30-5:00 pm 

Concurrency Control: 

Tom Haigh, Session Chair 

• A Multilevel Transaction Problem for 
Multilevel Secure Database Systems and 
Its Solution for the Replicated Architec¬ 
ture, Oliver Costich, John McDermott 

• A Two-Snapshot Algorithm for 
Concurrency Control Algorithm in Secure 
Multi-Level Databases, Paul Ammann, 
Frank Jaeckle, Sushil Jajodia 

• Alternative Correctness Criteria for 
Concurrent Execution of Transactions in, 
Multilevel Secure Database Systems, 
Sushil Jajodia, Vijayalakshmi Atluri 

5:00 pm T echnical Committee 

Business Meeting 

8:00 pm Poster Sessions 


2:00 pm Post-Symposium 

Sessions 

For registration information, 
please contact: 

Teresa Lunt, Symposium Vice Chair, 

SRI International, EL 245,333 Ravenswood 
Avenue, Menlo Park, CA 94025 
Phone: 415/859-3285 
Email: luntzel@csl.sri.com 

For hotel reservations contact: 

The Claremont Resort, Ashby and Domingo 
Avenues, Oakland, CA 94623-0363. 

Phone: 510/843-3000; Fax: 510-843-6239. 
Mention that you are attending the IEEE 
Symposium on Research in Security and 
Privacy to receive the conference rate of 
$91 /single or $103/double. The cut-off date 
is April 2; reservations made after this date 
will be accepted on a space available basis. 


^ IEEE Computer Society 


sponsored by the IEEE Computer Society Technical Committee on 
Security and Privacy 

in cooperation with the International Association of Cryptologic Research 























CAREER OPPORTUNITIES 


RATES: $15.00 per line (ten lines 
minimum). Average five typeset words 
per line, eight lines per column inch. Add 
$10 for box number. Send copy at least 
one month prior to publication date to: 
Marian B. Tibayan, Classified 
Advertising, COMPUTER Magazine, 
10662 Los Vaqueros Circle, PO Box 
3014, Los Alamitos, CA 90720-1264; 
(714) 821-8380; fax: (714) 821-4010. 

In order to conform to the Age Discrimina¬ 
tion in Employment Act and to discourage 
age discrimination, COMPUTER may re¬ 
ject any advertisement containing any of 
these phrases or similar ones: “...recent 
college grads...,” “...1-4 years maximum 
experience...,” “...up to 5 years experi¬ 
ence,” or “...10 years maximum experi¬ 
ence.” COMPUTER reserves the right to 
append to any advertisement without spe¬ 
cific notice to the advertiser. Experience 
ranges are suggested minimum require¬ 
ments, not maximums. COMPUTER as¬ 
sumes that since advertisers have been 
notified of this policy in advance, they 
agree that any experience requirements, 
whether stated as ranges or otherwise, will 
be construed by the reader as minimum re¬ 
quirements only. COMPUTER encour¬ 
ages employers to offer salaries that are 
competitive, but occasionally a salary may 
be offered that is significantly below cur¬ 
rently acceptable levels. In such cases the 
reader may wish to inquire of the employer 
whether extenuating circumstances apply. 


SOGANG UNIVERSITY 
Republic of Korea 

Department of Computer Science 

The Department of Computer Science at 
Sogang University is looking for qualified 
candidates for the position of assistant pro¬ 
fessor, with a desired starting date of Sep¬ 
tember 1, 1992. 

Areas of interest within the Department 
are Computer Network and Communica¬ 
tion, Computer Graphics and Programming 
Language. Duties include teaching at the 
undergraduate and graduate levels, advising 
students, and conducting research. Candi¬ 
dates must have a doctorate in Computer 
Science, Computer Engineering or a related 
field. Preference will be given to individuals 
with extensive research experience. Inter¬ 
ested persons should send a curriculum vitae 
to Dr. Seog Park, Chair, Department of 
Computer Science, Sogang University, 
C.P.O. Box 1142, Seoul 100-601, Republic 
of Korea. Phone: +82 + 2-705-8487. 
Fax: +82 + 2-705-8409. E-mail: spark@ 
KRSOG ANG. bitnet. 


SYSTEMS SOFTWARE ENGINEER 

Work with team developing Relational 
Database Management System based on the 
non-first normal form relational data model, 
which must run on both UNIX and VAX 
VMS. Use knowledge of UNIX, VMS kernel 
internals to improve functionality, perfor¬ 
mance. Re-engineer systems software be¬ 
tween UNIX and VMS. Use UNIX system 
calls and VMS system services extensively, 
with emphasis on IPC, share memory man¬ 
agement, lock management and perfor¬ 
mance. Requires Master’s in Computer Sci¬ 
ence + 3 years experience in systems soft¬ 
ware development, including development 
of relational theory-based database systems. 
Also requires proficiency in UNIX and VMS 
system programming in “C” and system 
utilities/tools. 40 hrs./wk., $42,000/yr. 
Mail resume to: Colo. Dept, of Labor, 600 
Grant, Ste. 900, Denver, CO 80203-3528, 
Attn: Employment Programs, and refer to 
Order No. C03773916, no later than April 
16, 1992. 


UNIVERSITY OF VERMONT 
Endowed Chair in 
Computer Science 

Applications are invited in Computer Sci¬ 
ence for the Dorothean Chair in the College 
of Engineering and Mathematics for the 
1992-93 academic year. It is anticipated that 
the position will be filled at the level of Full 
Professor. The successful candidate is ex¬ 
pected to assume a leadership role, teach 
mainstream computer science, and develop 
an externally funded research program. An 
established record of excellence in teaching 
and research in computer science is re¬ 
quired. Candidates should have demon¬ 
strable expertise in networks and distributed 
systems, database and knowledge base sys¬ 
tems, or parallel algorithms and systems, 
together with a strong interest in inter¬ 
disciplinary research in the mathematical 
sciences. Faculty are encouraged to super¬ 
vise graduate'students in related fields as well 
as in computer science. A doctorate in com¬ 
puter science or a closely related field is 
required. 

Applications will be accepted until the 
position is filled. Please submit resume and 
description of current research interests, and 
arrange to have three letters of recommen¬ 
dation sent directly to Dorothean Search 
Committee, 101 Votey, College of Engi¬ 
neering & Mathematics, University of Ver¬ 
mont, Burlington, VT 05405. Inquiries may 
be made to this address or by email to: 
cssrch@uvm.edu. The University of Ver¬ 
mont is an Affirmative Action/Equal Oppor¬ 
tunity employer and encourages applica¬ 
tions from women and members of minority 
groups. 


SOUTHERN METHODIST UNIVERSITY 
Computer Science and Engineering 

The Department of Computer Science 
and Engineering (CSE) invites applications 
for a junior (acuity position in Computer 
Engineering at the Assistant Professor level. 
Applicants must have a Ph.D. in Computer 
Engineering. Computer Science, or a related 
discipline. It is anticipated that the position 
will be filled by August. 1992. 

SMU is a private university with approx 
imately 8.000 students. The Department of 
Computer Science and Engineering is in the 
School of Engineering and Applied Science, 
where a close working relationship exists 
with the Departments of Electrical Engineer¬ 
ing and Mechanical Engineering. The CSE 
Department presents a balanced program of 
research and education at all levels and has 
been offering Ph.D. degrees since 1970. 
The Department has extensive contacts with 
computer-related and engineering-oriented 
industrial firms that distinguish Dallas as one 
of the top centers for high technology. 

Applicants should send a complete re 
sume. including the names of at least three 
references to: 

Professor Margaret H. Eich 
Chair. Faculty Search Committee 
Department of Computer Science 
and Engineering 
Southern Methodist University 
Dallas. Texas 75275-0122 
SMU is an equal opportunity/affirmative 
action. Title IX employer. Applications from 
women and minorities are particularly en¬ 
couraged. Applications will be accepted until 
April 15. 1992. 


McGill university 

Electrical and Computer Engineering 

The Department of Electrical Engineering 
of McGill University has a tenure-track open¬ 
ing at the assistant professor level in the area 
of computer engineering, which it would like 
to fill not later than September 1992. Ap¬ 
plications are invited from individuals who 
are dedicated to teaching, and who have 
outstanding research potential and demon¬ 
strated research achievements. Preference 
will be given to candidates with post-doctoral 
experience in software engineering. 

Candidates must have an earned Ph.D. 
degree, while a first degree in electrical 
engineering is desirable. Please send a 
resume and a list of 3 references to Professor 
Nicholas C. Rumin. Chairman, Department 
of Electrical Engineering, McGill University, 
3480 University St., Montreal, Quebec, 
H3A 2A7. 

In accordance with Canadian Immigration 
requirements, this advertisement is directed 
in the first instance to Canadian citizens and 
Permanent Residents of Canada. 
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DEVELOPMENT STAFF MEMBER 

Conduct research and development of 
heterogeneous distributed systems. Design 
and implement efficient technologies for 
remote procedure call (RPC) systems in 
heterogeneous and distributed computing 
environment. Devise performance optimiza¬ 
tion techniques for remote procedure com¬ 
munication protocols and data interface in 
distributed systems. 40 hrs./wk., $54,000/yr. 
Must have Ph.D. in Computer Science/or 
Computer Engineering, and one year exper¬ 
ience on the job or one year experience as a 
pre or post doctoral research/or teaching 
assistant. The one year related experience 
must include research and development in 
the design and implementation of a proto¬ 
type heterogeneous distribution-system; and 
evaluation and optimization of remote pro¬ 
cedure call systems’ performance on both 
communication protocols and data inter¬ 
faces. Must have publications on technol¬ 
ogy /performance of remote procedure call 
system, communication protocols, and data 
interface specification language. Apply at the 
Texas Employment Commission, Austin, 
Texas, or send resume to the Texas Employ¬ 
ment Commission, TEC Building, Austin, 
Texas 78778, J.O. #6421896. Ad paid by 
an equal employment opportunity employer. 


D.E. SHAW & CO. 

Algorithmic Trading 

D.E, Shaw & Co. is a small (several dozen 
employees), highly capitalized (over $300 
million in partners' equity), extremely suc¬ 
cessful Wall Street firm specializing in quan¬ 
titative finance and computational trading. 
Computer scientists and system designers 
form the professional core of the firm, and 
not merely its support staff, and participate in 
its profits. Our technical staff includes both 
Ph.D.-level researchers recruited from Stan¬ 
ford, MIT. and other leading computer sci¬ 
ence departments and extraordinarily talented 
B.S.-and M.S.-level system designers and 
“superhackers". It is our practice to compen¬ 
sate unusually gifted individuals at a level ex¬ 
ceeding that of the market. Applicants should 
send resumes to Jennifer Strulson. D.E. 
Shaw & Co.. 39th Floor, Tower45. 120 W. 
45th St.. New York. NY 10036. 


CASE INSTITUTE OF TECHNOLOGY 
NORD Professorship in 
Computer Engineering and Science 

The Department of Computer Engineer¬ 
ing and Science at Case Institute of Technol¬ 
ogy is seeking a nationally recognized 
scholar and researcher to fill the NORD Pro¬ 
fessorship. This position was recently estab¬ 
lished by the donation of over one and a half 
million dollars, which will provide outstand¬ 
ing professional opportunities and a highly 
competitive salary, together with additional 
funds for travel, graduate student support 
and equipment. The qualifications include a 
Ph.D. in computer science, computer engi¬ 


neering or closely allied fields, and an ability 
to establish and develop external support for 
a nationally recognized research program in 
computer science/computer engineering. 
We encourage applicants in all research 
areas, but our current research thrusts are in 
computer architecture and VLSI design, 
software engineering and systems, database 
systems, and artificial intelligence and logic 
programming. 

CWRU is a private university with a total 
enrollment of 8,400. of which 5,100 are 
graduate and professional students. The 
Engineering School of Case Institute of 
Technology is among the top ten engineer¬ 
ing schools in terms of research funding per 
faculty member and undergraduate student 
quality. The University campus is the hub of 
the pleasant area known as University Circle, 
an incorporation with neighboring cultural 
centers and museums, about five miles from 
downtown Cleveland. 

The Department of Computer Engineer¬ 
ing and Science has 13 faculty positions, and 
a graduate student body of 140 students, 60 
of which are in the Ph.D. program. Depart¬ 
mental facilities are based upon an ethernet 
local area network, connected to INTER¬ 
NET. which supports a UNIX operating sys¬ 
tem and about 40 SUN and other work¬ 
stations. In addition, faculty and students 
participating in the Center for Automation 
and Intelligent Systems Research have ac¬ 
cess to the Center's computing facilities. 

Applicants should submit their curriculum 
vitae and names of at least five references to: 
Lee J. White, Chairman, Department of 
Computer Engineering and Science, 
Case Western Reserve University, Cleve¬ 
land, Ohio 44106: INTERNET: leew@ 
alpha.ces.cwru.edu; applicants may wish to 
provide at most three reprints of their most 
important publications. 

An equal employment and affirmative ac¬ 
tion employer. 


DEFENSE ADVANCED RESEARCH 
PROJECTS AGENCY 
Deputy Director 

The Defense Advanced Research Projects 
Agency (DARPA), with a mission to engage 
in advanced military research projects essen¬ 
tial to the Department of Defense, is seeking 
candidates for the position of Deputy Direc¬ 
tor. The successful candidate will share re¬ 
sponsibility for oversight of both basic re¬ 
search and exploratory development efforts. 
Further, the individual selected for this posi¬ 
tion will play a key role in the continued ad¬ 
vancement of computer and communications 
technology which is essential if the U.S. is to 
maintain leadership in these critical areas. 

Requirements: In addition to superior 
technical management skills, applicants must 
have a degree in computer science, elec¬ 
tronic engineering, physics, or mathematics 
(a Ph.D. is highly desirable); must be a 
recognized technical authority in many of the 
technology areas currently pursued by DAR¬ 
PA (Computer Science, Artificial Intelli¬ 
gence, Computer Architecture, Software 
Engineering, Manufacturing process tech¬ 
nology, Robotics, and Advanced Mathema¬ 
tics) ; must have a working knowledge of the 
Federal budget development and appropria¬ 


tion process; and must have demonstrated 
ability to provide technical direction to a 
large, multiple effort R&D organization with 
projected resources for FY92 in excess of 
$1.5B. Must be able to obtain DoD security 
clearances. 

This position is in the Federal Senior Ex¬ 
ecutive Service. Salary range is $90,000 - 
$112,100 per year. Special forms are re¬ 
quired. Contact Kay Rogers at (703) 697- 
9557 for application guidance. Closing date 
for receiving applications is April 17, 1992. 

Affirmative Action/Equal Opportunity 
Employer. 


DEVELOPMENT STAFF MEMBER 

Engage in research and development in 
the areas of systems architecture, integrated 
circuit design, performance analysis, and 
computer graphics systems. Specific duties 
include development of digital signal pro¬ 
cessing (DSP) architectures for graphics 
systems, design of integrated circuits, and 
implementation of algorithms in VLSI de¬ 
signs for next generation computer graphics 
systems, and their possible extensions to the 
high-definition television (HDTV) field. 40 
hrs./wk., $56,000/yr. Must have a Ph.D. in 
Computer Science/or Computer Engineer¬ 
ing, and one year experience on the job or 
one year experience as a pre or post doctoral 
research staff/or assistant. The one year ex¬ 
perience must include development of high¬ 
speed VLSI systems, design of integrated cir¬ 
cuits, development and implementation of 
digital signal processor (DSP) architecture, 
use of computer aided design tools, and de¬ 
sign of custom-integrated circuits for TV 
signal processing. Apply at the Texas Em¬ 
ployment Commission, Austin, TX, or send 
resume to the Texas Employment Commis¬ 
sion, TEC Building, Austin, Texas 78778, 
J.O. #6421897. Ad paid by an equal 
employment opportunity employer. 


UNIVERSITY OF ARKANSAS 
Computer Systems Engineering 
Department 

The Computer Systems Engineering De¬ 
partment invites applicants for a tenure- 
track, Assistant Professor position. Appli¬ 
cants must hold a Ph.D., and preference will 
be given to candidates with engineering 
backgrounds. Responsibilities include teach¬ 
ing (undergraduate and graduate) and re¬ 
search. The Department has a diversity of' 
equipment and laboratories and provides ex¬ 
cellent opportunities for research and teach¬ 
ing development. Letters of interest and 
resumes will be accepted until March 31, 
1992, or subsequently, until the position is 
filled. Mail to: 

Dr. Ronald W. Skeith 
Professor and Head 
Computer Systems Engineering 
Department 
University of Arkansas 
Engineering Hall 313 
Fayetteville, AR 72701 
The University of Arkansas is an Equal 
Opportunity/Affirmative Action Employer. 
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UNIVERSITY OF ILLINOIS 
Department ol Electrical and 
Computer Engineering 

The Department of Electrical and Com¬ 
puter Engineering invites applications for 
several tenure-track and tenured faculty 
positions. Applicants must have an earned 
Ph.D.’s outstanding academic credentials, 
and an ability to teach effectively at both the 
graduate and undergraduate levels. Selected 
candidates will be expected to initiate and 
carry out independent research and to per¬ 
form academic duties associated with our 
B.S., M S., and Ph.D. programs. Since the 
department is very large, each year several 
vacancies are filled. A continuing search is 
conducted throughout the year to fill open 
positions. All candidates judged as qualified 
for a position will be interviewed. Salary 
open, based on qualifications. Starting date 
is negotiable. The department has one of the 
largest programs in the United States grant¬ 
ing approximately 400 B.S., 100 M.S., and 
65 Ph.D. degrees annually. The department 
is recruiting faculty in all areas of computer 
engineering. Current research interests of 
our computer engineering faculty include 
computer architecture, design complexity 
and theory of computation, high perfor¬ 
mance and reliable computing, knowledge 
engineering, parallel and distributed process¬ 
ing, performance evaluation, robotics and 
computer vision, and VLSI design. 

Send resume, with references and a list of 
publications to: T.N. Trick, Faculty Search 
Committee, University of Illinois, Depart¬ 
ment of Electrical and Computer Engineer¬ 
ing. 1406 West Green Street, Urbana, IL 
61801. Telephone: (217) 333-2301. 

The University of Illinois is an equal op¬ 
portunity/affirmative action employer. 


DATABASE SYSTEM SOFTWARE 
ENGINEER 

Designs and implements major compo¬ 
nents of a state-of-the-art object-oriented 
database system, and ports system to various 
operating systems. Components to be im¬ 
plemented include the query processor, a 
B+ - tree index manager and a database 
catalog manager. Porting systems will in¬ 
clude MS/DOS, VMS, and MVS. Must 
have MS in Computer Science or Computer 
Engineering and 2 years experience in Com¬ 
puter Engineering, Computer Science, or 
Computer related teaching (academic or 
employment). Employer will accept 2 years 
academic research, academic employment, 
or other employment or any combination of 
experience. Must have strong background in 
theory and implementation of relational 
database systems, and object-oriented data¬ 
bases. Knowledge of MS/DOS, VAX, Unix 
and query and rule processing technologies. 
Strong ability to program in C, and C + +. 
1 strong reference. 40 hours per week, 8:00 
a.m. to 5:00 p.m. $35,302 per year. Apply 
at the Texas Employment Commission, 
Austin, Texas, or send resume to the Texas 
Employment Commission, TEC Building, 
Austin, Texas 78778, J.O. #6521614. Ad 
Paid by an Equal Employment Opportunity 
Employer. 


UTAH STATE UNIVERSITY 

Applications are invited for the position of 
assistant professor of Computer Science, 
with the expected start date of September, 
1992. Qualifications include demonstrated 
ability in or the promise of quality research 
and teaching. We seek an outstanding appli¬ 
cant who will add to our existing research 
strengths in parallelism, Software Engineer¬ 
ing, or Artificial Intelligence. In addition, ap¬ 
plicants must have a Ph.D. in computer sci¬ 
ence or computer engineering by the date of 
appointment. 

The department currently offers B.S. and 
M.S. degrees in Computer Science. Suc¬ 
cessful candidates would be expected to as¬ 
sist in the development of a Ph.D. program. 

The university is located in a beautiful 
mountain valley with nearby skiing, hiking, 
and many other outdoor activities. 

Send resume and names of 3 references 
to: Faculty Search Committee, Computer 
Science, Utah State University, Logan, 
Utah, 84322-4205. Include name, address, 
telephone number and e-mail address (when 
available) of each reference. Send inquiries 
to e-mail address search@slow.cs.usu.edu. 
The position will remain open until filled. 

Women and minorities are encouraged to 
apply. U.S.U. is an EO/AAE employer. 


NEC RESEARCH INSTITUTE 
PRINCETON, NEW JERSEY 
Fundamental research in the 
computer and physical sciences 
in an environment supportive of 
long-term goals 

The Computer Science Research Division 
will have openings at all levels in selected 
areas of basic research. Junior candidates 
should have a Ph.D. in Computer Science or 
a related discipline and show outstanding 
research potential. Senior candidates should 
have a strong research record documented 
by publication in the open literature. Institute 
policy is to encourage publication of research 
results. Candidates in areas of computer ar¬ 
chitecture, systems, natural and computer 
languages, machine learning and intelli¬ 
gence, and related areas are of particular 
interest. Competitive salary and benefits in a 
collegial atmosphere close to major metro¬ 
politan centers. Candidates should satisfy all 
relevant US regulations regarding employ¬ 
ment. To apply, send resume and names of 
four or more references to: Vice President, 
Computer Science Research, NEC Research 
Institute, 4 Independence Way, Princeton, 
NJ 08540. 

The Institute is an equal-opportunity 
employer. 


Kuwait University 


College of Engineering & Petroleum 
Department of Electrical & Computer Engineering 

The Department of Electrical and Computer Engineering of Kuwait University invites applica¬ 
tions for permanent or visiting faculty positions starting September 1992. Duties include teaching 
courses at undergraduate and graduate levels. Applicants must have earned a doctorate degree in 
the field of Electrical Engineering, Computer Engineering or related disciplines. Areas of special 
interest include: Opteoelectronics, Photonics, Solid State Devices and Electronics, Neural Net¬ 
works and Circuits, Analog and Digital VLSI. Computer Engineering areas of interest include: 
Software Engineering, Operating Systems, ComputerNetworks, Graphics, Artificial Intelligence, 
Languages and Database Systems. 

The Department of Electrical and Computer Engineering is the largest department in the College 
of Engineering at Kuwait University with 400 students and 27 faculty members. Graduate school 
will be resumed September 1993. Teaching is emphasized in undergraduate and graduate labora¬ 
tories with a yearly laboratory budget of $2 million. Research utilization is encouraged for these 
laboratories. Research is supported through the Research Management Unit at Kuwait University 
with $3 million yearly budget for the College of Engineering. The Department of Electrical and 
Computer Engineering has an extensive computing environment consisting of a network of over 
a 100 Macs and PC’s, 40 SPARC2’s, three SPARCSeivers 470/490k, and a VAX 6000-510. The 
department has access to a VAX 9000-VP and an IBM ES9000 located on the campus of the Col¬ 
lege of Engineering. 

Faculty members enjoy many free benefits furnished by Kuwait University. These benefits in¬ 
clude: medical care, private education (up to 12th grade) yearly home travel with family and free 
housing. 


Applications forms and Conditions of Service 


Completed applications with names of three 

may be obtained from: 


referees should be returned to: 

Embassy of the State of Kuwait 


Dr. Abbas Maarafi, Dean 

Kuwait University Office 


College of Engineering and Petroleum 

3500 International Drive, N.W. 


Kuwait University 

Washington, DC 20008 


P.O. Box 5909 Safat 13060 

Tel: 202-363-8055 


Kuwait 

Fax: 4811772 Tel: 4811188 ext/5180 


The first deadline is March 30,1992 or the 30th of each month until positions are filled. 
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NORTHEAST 
LOUISIANA UNIVERSITY 

Applications are invited for a tenure track 
assistant or associate professor in a CSAB 
accredited computer science program. Can¬ 
didates should have a Ph.D. in computer sci¬ 
ence preferably with emphasis in software 
engineering and a strong commitment to 
teaching. Teaching load is 6-9 hours with 
competitive salary and twenty year retire¬ 
ment program. Applications will be accepted 
until position is filled. Applicants should send 
a resume, transcripts, and three references 
to Dr. Kris Cooper. Chair, Search Commit¬ 
tee, Department of Computer Science. 
Monroe. LA 71209-0575. Phone (318) 
342-1856. NLU is an Equal Opportunity Af¬ 
firmative Action Employer. 


UNIVERSITY OF CALIFORNIA 
BERKELEY 

The University of California at Berkeley 
invites applications for TEMPORARY and 
VISITING POSITIONS. The COMPUTER 
SCIENCE Division of the Department of 
Electrical Engineering and Computer 
Sciences, pending budgetary approval, may 
have openings for visiting and temporary 
faculty to teach courses full or part time in 
computer science during the 1992-93 aca¬ 
demic year. Specific teaching needs will be 
known by Spring, 1992, and may include 
courses in introductory programming, com¬ 
puter hardware and architecture, program¬ 
ming languages, operating systems, data 
structures, computer science theory, graphics, 
artificial intelligence, and computer networks. 

Applicants will be considered on their aca¬ 
demic qualifications, teaching experience, 
research record, recommendations, and 
other relevant experience. Applicants should 
send a resume, with the names and ad¬ 
dresses (including telephone numbers and 
electronic mail addresses) of at least three 
references, copies of all relevant teaching 
ratings, and lists of courses that could be 
taught, as soon as possible, but no later than 
April 1, 1992, to the address below. 

Professor David Patterson 
Chair for Computer Science 
EECS Department 
University of California 
Berkeley, CA 94720 

The University of California is an Equal 
Opportunity Affirmative Action Employer. 


THE UNIVERSITY OF WAIKATO 
HAMILTON NEW ZEALAND 
Lecturers in Computer Science 

Due to continuing growth, applications 
are invited for positions at Lecturer level in 
the Department of Computer Science. The 
University of Waikato. Hamilton. New Zea¬ 
land. Applicants should have strong re¬ 
search interests in any areas of Computer 
Science or Information Systems. Teaching 


experience in senior and graduate courses 
in. software engineering, information sys¬ 
tems or computer technology will be helpful, 
while experience in administering and teach¬ 
ing large first year courses will be of particular 
interest for one of the positions. 

The Department of Computer Science has 
a complement of 28 academic and support 
staff, and is the fifth largest department in the 
University, Its staff teach and conduct re¬ 
search in both computer science and infor¬ 
mation systems areas. There are 2500 stu¬ 
dent course enrollments, and majors in 
Computer Science are granted in five under¬ 
graduate degrees. Graduate study is under¬ 
taken at the masters and doctoral level. Staff 
research interests include speech recogni¬ 
tion, software engineering, parallel com¬ 
putation, languages, data modelling, human 
computer interfaces and machine learning. 
As well as a large networked MS DOS teach¬ 
ing laboratory, departmental resources in¬ 
clude a SUN workstation laboratory, hard¬ 
ware and communication laboratories, a 
variety of Unix servers, and access to the 
University's VAX clusters. Internet access to 
email and netnews is available. 

The University of Waikato is the fastest 
growing of the seven universities in New 
Zealand and currently has over 9.000 stu¬ 
dents. The campus and surrounding area 
are very attractive, bordering a pleasant rural 
district on the eastern edge of Hamilton, 
a modern city of 100.000. Climate is moder¬ 
ate. . the grass grows year round. . .and 
the temperatures are not extreme in any 
part of the year. In short, the lifestyle is 
unbeatable! 

Candidates for this position should be able 
to demonstrate a record of accomplishment 
and experience in both teaching and re¬ 
search . in one or more areas of computer sci¬ 
ence or information systems. Candidates 
should hold (or expect to shortly complete) 
a doctorate in Computer Science. Informa¬ 
tion Systems, or a related field. The present 
salary scale for lecturers is $NZ37.440 
- SNZ49.088 per annum. 

Enquiries of an academic nature may be 
made to the Chairperson of the Department. 
Dr. Lloyd Smith, telephone (64) 7 8562889. 
Fax (64) 7 8384066 email las@waikato.ac.nz 
(via Internet). Information on the method of 
application and conditions of appointment 
can be obtained from the Academic Staff 
Unit. University of Waikato. Private Bag 
3105. Hamilton. New Zealand, telephone 
(64) 7 8562 889. Fax (64) 7 8560135. Ap¬ 
plications quoting reference number 
A91/101 should reach the Academic Staff 
Unit by 10 April 1992. 

The University welcomes applications 
from suitable people regardless of race, 
creed, marital status, or disability. 


SYSTEMS ENGINEER 

Requires: B.S. in Electrical Engineer¬ 
ing/Computer Science; one year experi¬ 
ence in job offered or in electrical/electronic, 
software, or systems engineering or analysis; 
and thorough knowledge of and experience 
with: high speed laser printer controller 


design, Macintosh printer driver applications 
and digital communications protocols, ad¬ 
vance level programming languages and 
VAX/VMS, and microprocessor/micro¬ 
computer-based systems design using de¬ 
vices such as Motorola 68000 and TI-34010. 

Duties: designs microprocessor and micro- 
computer-based systems using digital circuit 
and software design techniques; designs 
computer peripheral equipment including 
laser printers and print engine interfaces and 
direct memory access (“DMA") controllers; 
develops and tests digital circuit boards to 
support digital products; diagnoses and cor¬ 
rects hardware and software product design 
flaws; analyzes data processing requirements 
to determine electronic data processing 
system to provide system capabilities re¬ 
quired for projects or workloads, and plans 
layout of system installation or modification 
utilizing knowledge of electronics and data 
processing principals and equipment; deter¬ 
mines, recommends, and designs new hard¬ 
ware, software, and peripheral equipment, 
or modifications to existing equipment and 
systems; designs, develops, tests and super¬ 
vises initial usage and support for such sys¬ 
tems. Up to three positions open. $35,940/ 
yr. 40 hrs./wk. E.O.E. Apply or send 
resume to: D. Abernathy, Alabama State 
Employment Services, 4130-C Government 
Blvd., P.O. Box 190399, Mobile, Alabama 
36619. #AL 0625442. 


UNIVERSITY OF 
CALIFORNIA, IRVINE 
Graduate Fellowship 

Western Digital Corporation has provided 
funds to the Department of Electrical and 
Computer Engineering at the University of 
California, Irvine to establish a fellowship 
program intended to foster research in VLSI 
Systems Engineering. 

This will be a two-year fellowship normally 
leading to a Master’s degree, but Ph.D. 
students are not excluded. There will be two 
such fellowships awarded. Two faculty 
members in adjacent thrust areas will identify 
a joint research topic, and the fellowship will 
be offered to graduate students to the joint 
research area. The area should relate to 
implementing systems in silicon, with 
Western Digital funding the cost of procuring 
prototypes of VLSI chips. 

The stipend for each student is $18,000, 
plus tuition and fees. Western Digital will also 
offer summer employment to the Fellows; 
however there will be no obligation on the 
part of the Fellow to accept this summer 
employment nor would there be an obliga¬ 
tion on either part regarding employment 
with Western Digital at the end of the 
Fellowship period. 

The candidates must be U.S. citizens, and 
it is preferred that they have excellent com¬ 
munication and leadership skills. The 
Department of Electrical and Computer 
Engineering welcomes applications from 
women and minority candidates. UCI is an 
Affirmative Action/Equal Opportunity 
Employer. Send resumes to Dr. Leonard A. 
Ferrari, Eng. I, Room 305, University of 
California, Irvine, CA 92717. 
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NEW JERSEY INSTITUTE 
OF TECHNOLOGY 
Foundation Chair in 
Information Systems 

N JIT seeks outstanding researcher as pro 
fessor and holder of newly established Foun¬ 
dation Chair in Information Systems to lead 
a program of instruction and research in in¬ 
formation systems, including management 
and applications. 

Qualifications'. Ph.D. in information sys 
terns, computer science or closely related 
field. Proven research, publication and fund 
ing record. Commitment to both research 
and teaching excellence. 

The Department of Computer and Infer - 
mation Science offers B.S.. B.A.. M.S. and 
Ph.D. degrees in computer science as well as 
B.S. and M.S. degrees in information svs 
terns. Computer facilities include the $30 
million Guttenberg Information Technolo 
gies Building with VAX SHOO. VAX 6430. 
DEC 5500. NCUBE. SUN WORKSTA 
TIONS. and graphics systems. 

NJIT is the technological university of 
New Jersey with approximately 7500 stu 
dents enrolled in Newark College of Engi 
neering. the School of Architecture, the Col¬ 
lege of Science and Liberal Arts, and the 
School of Industrial Management. Send re 
sume and names of three references to: Per¬ 
sonnel Box CIS. New Jersey Institute of 
Technology. University Heights. Newark. 
NJ 07102. 

NJIT does not discriminate on the basis of 
sex. race, color, handicap, religion, national 
or ethnic origin or age in employment. 


UNIVERSITY OF OREGON 
Senior Faculty Position/ 
Department Head 

The Department of Computer and Infor¬ 
mation Science invites applications for a 
senior faculty position created by a new state 
Centers of Excellence award. We are seek¬ 
ing a person who will be an active leader in 
the department, willing to serve one or more 
terms as department head and also play a 
key role in relations to the computer in¬ 
dustry. Applicants should have a Ph.D. in 
computer science or related field and a 
distinguished record of teaching and re¬ 
search in the area of parallel processing (in¬ 
cluding parallel architectures, languages, 
and performance modeling) or human-com¬ 
puter interaction (including computer 
graphics and scientific visualization). Our 
department has 14 other faculty positions 
(including one other new position for which 
we are currently recruiting), approximately 
20 Ph.D. students, 50 M.S. students, and 
150 B.S. students. We have strong research 
programs in parallel and distributed systems, 
computer graphics, user interfaces, pro¬ 
gramming languages, software engineering, 
artificial intelligence, and theoretical com¬ 
puter science, and active interdisciplinary ties 
with other on-campus groups in the fields of 
cognitive science, neuroscience, economics, 
biology, physics, and mathematics. We offer 
a modern computing environment (a MasPar 
MP-1100, two Sequent Symmetry multipro¬ 
cessors, and dozens of Sun and HP worksta¬ 


tions) housed in a new computer science 
building. 

Review of applications will begin on April 
15 and continue until the position is filled. 
The position is available September, 1992, 
with a target date to fill the position by 
January, 1993. Qualified applicants should 
send their curriculum vitae and the names of 
at least three references to: Professor John 
S. Conery, Faculty Search Committee, De¬ 
partment of Computer and Information Sci¬ 
ence, University of Oregon, Eugene, OR 
97403-1202. For more information send 
e-mail to conery@cs.uoregon.edu or phone 
(503) 346-3973. We especially encourage 
applications from women and minorities; the 
University of Oregon is an Equal Oppor¬ 
tunity/Affirmative Action Employer com¬ 
mitted to cultural diversity. 


DUKE UNIVERSITY 
Dept, of Electrical Engineering 

The Department of Electrical Engineering 
at Duke University seeks an experienced 
candidate for a tenure track or tenured facul¬ 
ty position in the area of computer engineer¬ 
ing. The applicant should have a Ph.D., a 
strong and documented research record, 
and a dedication to excellence in teaching. 
We are particularly interested in a person 
with interests in fault-tolerance and test¬ 
ability, high performance computing, com¬ 
puter networks or VLSI design and CAD 
tools. Interested persons should send a cur¬ 
riculum vitae and the names, addresses and 
phone numbers of five references to: Kishor 
Trivedi, Computer Engineering Search 
Committee, Department of Electrical Engi¬ 
neering, Duke University, Durham, NC 
27706. Duke University is an equal oppor¬ 
tunity/affirmative action employer. 


THE UNIVERSITY OF TENNESSEE 
Department of Computer Science 
Knoxville, Tennessee 37996-1301 

The Department of Computer Science in¬ 
vites applications for tenure-track positions at 
the rank of Professor beginning Fall 1992. 
A strong research record in the areas of 
operating systems, scientific computing or 
software engineering is sought but all major 
fields in computer science may be con¬ 
sidered. Experience directing doctoral 
students is especially important. Tenure- 
track positions for Associate and Assistant 
Professors are also open. Applicants for 
Associate Professor should have a strong 
research record, preferably in the above- 
named areas; experience directing doctoral 
students is desirable. Applicants for Assistant 
Professor should have a strong interest in re¬ 
search, preferably in the above-named areas. 
Applicants for all positions should have a 
doctoral degree in computer science or a 
related area. 

Departmental SUN, IBM and DEC work¬ 
stations abound for students and faculty and 
are fully networked. In addition, the depart¬ 
ment has acquired a Thinking Machine CM-5. 


The department and the Mathematical 
Sciences Section of the Oak Ridge National 
Laboratory jointly operate the Advanced 
Computing Laboratory which includes fully 
networked Intel iPSC/860, 128 processors; 
iPSC/2, 64 processors; two Sequent 
Balances and a Sequent Symmetry; a Star- 
dent Titan with four processors; Cogent; 
N-Cube; Kendall Square Research machine 
with 32 processors; and various file servers. 
Also, Oak Ridge National Laboratory is ac¬ 
quiring an Intel Paragon. In addition, the 
department has recently received an NSF 
Small-Scale Infrastructure Award. The de¬ 
partment is part of the National Science 
Foundation Science and Technology center 
for Research in Parallel Computing. The 
University operates an IBM 3090 and a large 
VAX cluster. 

Please respond to straight@cs.utk.edu. 
The mailing address is Department of Com¬ 
puter Science, 107 Ayres Hall, The Univer¬ 
sity of Tennessee, Knoxville TN 37996-1301. 

The University of Tennessee is an EEO/ 
AA/TITLE IX/SECTION 504/ADA 
employer. 


UNIVERSITY OF HONG KONG 
Faculty of Engineering 
Reader/Senior Lecturer/Lecturer in 
Computer Science and 
Information Systems 

Department of Computer Science 
(Reg. RF/TA/Engg/4) 

Candidates should have a higher degree 
in Computer Science, Information Systems 
or Computer Engineering, and strong inter¬ 
est in both teaching and research. Extensive 
experience in supervising MPhil and Ph.D. 
students and an excellent research record 
are essential. Well-qualified applicants are 
sought in all areas of Computer Science but 
especially in Information Systems, Logic 
Programming, Artificial Intelligence, 
Graphics, Computer Vision, Software Engi¬ 
neering, Database and Neural Network. 

Salary per annum (superannuable) is on 
the following scales: 

Reader(R) HK$501,120 - 665,700 (9 
points) (US$64,861 - US$86,164) 

Senior Lecturer (SL) HK$480,360 - 
645,300 (9 points) (US$62,175 - 
US$83,522) 

Lecturer (L) HK$309,120 - 516,480 (11 
points) (US$40,010 - US$66,850) 

US Dollar equivalents as at 14 January 
1992. Starting salaries depend on qualifica¬ 
tions and experience. At current rates, 
salaries tax will not exceed 15% of gross in¬ 
come. Children’s education allowances, 
leave and medical benefits are provided; 
housing or tenancy allowances are also pro¬ 
vided in most cases at a charge of 7.5% of 

Further particulars and application forms 
may be obtained from Appointments 
(40262), Association of Commonwealth 
Universities, 36 Gordon Square, London 
WC1H OPF, UK; or from the Secretary, 
Faculty of Engineering, University of Hong 
Kong, Hong Kong (Fax (852) 5469142, 
E-mail HUUR-ENG @HKUVM. BITNET). 

Closes 1 May 1992. 


March 1992 


121 












BALL STATE UNIVERSITY 
MUNCIE, INDIANA 
Computer Science 

Faculty position available Fall 1992 in any 
major area of computer science. Background 
in software engineering, communication, or 
compilers preferred. Faculty will teach com¬ 
puter science courses for masters degree and 
undergraduate students. An active scholar¬ 
ship program is expected. Minimum Qualifi¬ 
cations: Ph.D. in computer science; ABD 
acceptable if degree is completed by Fall 
1993. Preferred Qualifications: Ph.D. in 
computer science; at least two years experi¬ 
ence in software development and teaching; 
excellent teaching record and several publi¬ 
cations. Send letter of application, resume, 
three letters of reference, ancj. official tran¬ 
scripts to Dr. Kunwarjit S. Bagga, Chair¬ 
person of Search and Selection Committee, 
Department of Computer Science, Ball State 
University, Muncie, IN 47306. Review of 
applications will begin March 30, 1992, and 
continue until the position is filled. 

Ball State University is an Equal Oppor¬ 
tunity, Affirmative Action Employer and is 
strongly and actively committed to diversity 
within its community. 


UNIVERSITY OF ILLINOIS 
AT URBANA-CHAMPAIGN 

Department of Computer Science 

The Department of Computer Science, 
University of Illinois at Urbana-Champaign, 
anticipates possible tenure or tenure-track 
appointments in several disciplines. Appli¬ 
cants must have outstanding academic cre¬ 
dentials and an ability to teach effectively at 
both the graduate and undergraduate levels. 
Successful candidates will be expected to in¬ 
itiate and carry out independent research 
and to perform academic duties associated 
with our BS, MS, and Ph.D. programs. In 
order to ensure full consideration, applica¬ 
tions must be received by April 15, 1992, 
although a search will continue until posi¬ 
tions have been filled. Ph.D. or imminent 
completion required. Salary open, based on 
qualifications. Starting dates are August 21, 
1992 or January 6, 1993. Send resume in¬ 
cluding names of three references to: Dun¬ 
can H. Lawrie, Head, Department of Com¬ 
puter Science, 1304 W. Springfield Avenue, 
Urbana, IL 61801. Phone (217) 333-6454. 
The University of Illinois is an Affirmative Ac¬ 
tion, Equal Opportunity Employer. 


THE GEORGE WASHINGTON 
UNIVERSITY 
Visiting Professorships 
Research Faculty/Research Staff 

Visiting Professorships, Research Faculty, 
and Research Staff Positions, at junior and 
senior levels, are available in the School 
of Engineering and Applied Science, The 
George Washington University starting Fall 
Semester 1992. The School of Engineering 
and Applied Science is organized into four 


academic departments: the Department of 
Civil, Mechanical and Environmental Engi¬ 
neering; the Department of Electrical Engi¬ 
neering and Computer Science; the Depart¬ 
ment of Engineering Management; and the 
Department of Operations Research. 

Candidates are especially sought to teach 
and/or conduct research in the following 
areas: Artificial Intelligence; Communica¬ 
tions; Computer Graphics; Computer-Inte¬ 
grated Design and Manufacturing; Computer 
Science; Computer Security; Data Net¬ 
works; Decision Support Systems; Energy 
Management; Engineering Management; In¬ 
formation Technology Management; Integer 
and Network Programming; Manufacturing/ 
Production Management; Mathematical Op¬ 
timization; Mechanical Engineering Design; 
Operations Research; Project and Program 
Management and Total Quality Manage¬ 
ment; Reliability; Simulation; Software 
Engineering; Stochastic Processes; Struc¬ 
tural Engineering; Systems Engineering; 
Technology Assessment and Transfer; and 
User-Computer Interface. 

Appointments are for up to one-year 
periods. Applications will be reviewed begin¬ 
ning February 1 and will be accepted until 
the positions are filled. Applicants should 
send vita, including complete publication list, 
and three references to: 

Visiting Engineers Scholars Program 

Research Faculty and Staff Program 
School of Engineering and 
Applied Science 

The George Washington University 
Washington, D.C. 20052 

The George Washington University is an 
Affirmative Action and Equal Opportunity 
Employer. 


PRODUCT DEVELOPMENT 
ENGINEER I 

Performs tasks relating to definition and 
design of VLSI (Very Large Scale Integra¬ 
tion) 32 bit microprocessor architectures, in¬ 
cluding logic design, simulation, and veri¬ 
fication and circuit design, sizing (utilizing 
HSPICE) verification, and debug via hard¬ 
ware and software. Oversees and partici¬ 
pates in mask design work including final lay¬ 
out, schematic capture and subsequent data 
bases. Supports product debug and charac¬ 
terization to determine product perfor¬ 
mance, process and test sensitivities. Utilizes 
C programming language on a UNIX oper¬ 
ating system. Provides central engineering 
support for the product(s) through all phases 
of development and/or manufacturing. Must 
have MS in Computer or Electrical Engineer¬ 
ing. Must have successfully completed 
coursework in the following areas: VLSI 
design, circuit design, circuit simulation, IC 
fabrication. Knowledge of C programming 
language and UNIX. 40 hours per week, 
8:00 a.m. to 5:00 p.m. $3545 per month. 
Apply at the Texas Employment Commis¬ 
sion, Austin, Texas, or send resume to the 
Texas Employment Commission, TEC Build¬ 
ing, Austin, Texas 78778, J.O. #6687501. 
Ad Paid by an Equal Employment Oppor¬ 
tunity Employer. 


Systems Analyst/Database Manager 

Systems Analyst/Database Manager 
needed to design, implement and maintain 
database system for the accounting, auditing 
and collection departments of a non-profit 
organization. Assess the present and future 
software and hardware needs with respect to 
real and anticipated growth. Analyze and 
identify user needs and resolve software 
problems on different software packages 
such as WordPerfect, DBase, Paradox3, 
Quattro, and Platinum. Prepare detailed 
analysis and design for the proposed applica¬ 
tion. Supervise and assist the technical sup¬ 
port team in the development of accounting 
applications for pledges and payment pro¬ 
cessing, generation of monthly pledge billing 
and reconcilliation reports, corporate match¬ 
ing processing generation of monthly billing 
and reconcilliation reports. Design and 
develop a database for applications. Re¬ 
quires a Bachelor’s degree in Computer Sci¬ 
ence and two years experience in job offered 
or two years experience in networking, data¬ 
base design and implementation experience. 
40 hour work week. $27,978.00 per year. 
Apply at the Texas Employment Commis¬ 
sion, Fort Worth, Texas, or send resume to 
the Texas Employment Commission, TEC 
Building, Austin, Texas, 78778, Job Order 
#6599179. Ad Paid by an Equal Employ¬ 
ment Opportunity Employer. 


THE UNIVERSITY OF CALIFORNIA 
AT IRVINE 

Department of Electrical and 
Computer Engineering 

The UCI Department of Electrical and 
Computer Engineering invites applications 
from outstanding candidates for tenure track 
position at the Assistant, Associate or full 
Professor level in the area of computer engi¬ 
neering. Senior candidates must have a 
strong record of research accomplishments 
through publication in the generally ac¬ 
cepted top research journals in the field, 
proven record for obtaining substantial extra¬ 
mural funding for supporting his/her re¬ 
search program, proven ability to teach 
undergraduate and graduate courses, exper¬ 
ience in guiding the research of students, and 
sense of responsibility for contributing to the 
welfare of the institution through committee 
service. It is expected that the candidates 
have a strong research record in one or more 
of the following areas: highly parallel com¬ 
puter systems, distributed computer systems, 
ultra-reliable real-time computer systems, 
and high-level computer design automation. 

Please send your complete curriculum 
vitae with at least three references to: 

Dr. Leonard A. Ferrari 
Department of Electrical and 
Computer Engineering 
University of California 
Irvine, CA 92717 

Applications submitted by March 15, 1992 
will receive full consideration. The De¬ 
partment of Electrical and Computer Engi¬ 
neering welcomes applications from women 
and minority candidates. UCI is an Affir¬ 
mative Action/Equal Opportunity Employer. 


122 


COMPUTER 







SOFTWARE DEVELOPMENT 
ENGINEER 

Software Development Engineer needed 
to analyze, design, document, implement 
and test software feature in the area of 
Group Special Mobile (GSM) for telecom¬ 
munications company. Debug and resolve 
software related problems reported by 
customers or system test for a special mobile 
system utilizing the UNIX environment. 
Assist designers in software development, 
including document review and code inspec¬ 
tions. Interact with other software engineers, 
system test, verification office and field sup¬ 
port. Interact with management on technical 
and administrative issues. Interact with 
customers during document review and field 
applications. Design software using high 
level languages. Solve technical problems 
that affect the performance of the GSM pro¬ 
duct in regards to feature functionality. 
Requires a Bachelor’s degree in Computer 
Science or its equivalent and two years ex¬ 
perience in job offered; or will consider the 
completion of all requirements for a Master’s 
degree in Computer Science in lieu of the 
Bachelor’s degree and two years experience. 
Background must include at least one se¬ 
mester in Telephony or Computer Networks 
and at least six months experience in Pascal 
programming language or two semesters in 
Pascal and three months UNIX experience, 
40 hour work week, $3,483.33 per month. 
Apply at Texas Employment Commission, 
Dallas, Texas or send resume to the Texas 
Employment Commission, TEC Building, 
Austin, Texas 78778. Job Order #6342849. 
Ad Paid by an Equal Employment Oppor¬ 
tunity Employer. 


NAVAL POSTGRADUATE SCHOOL 
Chair of Department 

The Computer Science Department of the 
Naval Postgraduate School seeks a Depart¬ 
mental Chair, with term beginning no later 
than 30 September 1992. The ideal candi¬ 
date holds a Ph.D. in Computer Science, is 
from an academic environment, and main¬ 
tains a continuing, strong involvement in re¬ 
search. We desire a candidate who facilitates 
the activities of departmental faculty and 
exerts leadership in developing department 
and interdisciplinary programs. The candi¬ 
date should possess strong interpersonal and 
written communication skills. The candidate 
must be an excellent teacher. 

The department offers graduate degrees 
with specialization tracks in artificial in¬ 
telligence and robotics, computer graphics 
and visual simulation, computer systems and 
architectures, database and data engineer¬ 
ing, and software engineering. The depart¬ 
ment currently has major applied research 
funding in software engineering, computer 
graphics/virtual reality, and artificial in¬ 
telligence/robotics. We believe that our 
future departmental growth areas will be in 
the areas of software engineering/real-time 
systems, computer graphics/virtual reality, 
and secure distributed systems. Conse¬ 
quently, we prefer a chair whose research 
area matches with one of our areas of growth 
though we will consider exceptional candi¬ 


dates from any area. U.S. citizenship is re¬ 
quired. Applicants interested in the position 
should forward their resume to: 

Associate Professor Michael J. Zyda 
Chair, Chair Search Committee 
Naval Postgraduate School 
Code CS/Zk, Department of Computer 
Science 

Monterey, California 93943-5100 
(408) 646-2305 

Email: zyda@trouble.cs.nps.navy.mil 
The Naval Postgraduate School is an 
Equal Opportunity/Affirmative Action 
Employer. 


NEW JERSEY 

INSTITUTE OF TECHNOLOGY 
Faculty: 

Computer and Information Science 

NJIT seeks assistant, associate and full 
Professors for Spring/Fall 1992 in distributed 
computing including computer architecture, 
operating systems, data communications 
and networking, realtime computing and 
fault tolerance; software development in¬ 
cluding compiling, computer graphics, office 
automation, data management systems, in¬ 
formation management systems, cognitive 
science, and computational linguistics; com¬ 
puter graphics and computer visions and 
other areas. Qualifications: Ph.D. in com¬ 
puter science or closely related field re¬ 
quired; senior level applicants must have 
proven research and funding record. 

The department offers B.S., B.A., M.S. 
and Ph.D. in computer science. Computing 
facilities include the $30 million Information 
Technologies Building with VAX 6400, 
VAX 8530, IBM 4361, SUN workstations. 
Symbolics machines. TI Explorers and 
graphic systems. Send resume and names of 
three references to: Personnel Box CIS-F. 

NJIT is the technological university of 
New Jersey with 7,500 students enrolled in 
Newark College of Engineering, the School 
of Architecture, the College of Science and 
Liberal Arts and the School of Industrial 
Management. 

NJIT does not discriminate on the basis of 
sex, race, color, handicap, religion, national 
or ethnic origin or age in employment. 

New Jersey Institute of Technology 

University Heights, Newark. NJ 07102 


UNIVERSITY OF WASHINGTON 

Department of Computer Science 
and Engineering 

The Department of Computer Science 
and Engineering at the University of 
Washington expects to have one or more 
tenure-track openings starting in the 
1992-93 academic year. We seek outstand¬ 
ing applicants who add to our existing 
research strengths, particularly in compilers, 
computer systems engineering, and software 
engineering, or who bring significant new 
research strength to our department. 

A moderate teaching load allows time for 
quality research and close involvement with 
students. We expect applicants to have a 
strong commitment to both research and 
teaching, and an outstanding record of 


research for their level. 

Interested applicants should send a letter 
of application, a resume, and the names of 
four references to Faculty Recruiting Com¬ 
mittee, Department of Computer Science 
and Engineering FR-35, University of Wash¬ 
ington, Seattle, Washington 98195. Candi¬ 
dates are encouraged to apply as early as 
possible. 

The University of Washington is an Affir¬ 
mative Action/Equal Opportunity Employer. 
The Ph.D. is required for these positions. 


DEVELOPMENT STAFF MEMBER 

Design and develop computerized sys¬ 
tems for managing the robotic assembly of 
electronic cards. Duties include develop¬ 
ment and implementation of decision sup¬ 
port systems for shopfloor control, setup 
management of assembly equipment, intelli¬ 
gent task planning, and automated process 
planning for electronic card assembly robots 
with integrated vision sensors. 40 hrs./wk. 
$55,000/yr. Must have Ph.D. in Computer 
Science/or Mechanical Engineering and one 
year experience on the job or one year ex¬ 
perience as a pre or post doctoral research/ 
teaching assistant. The one year related ex¬ 
perience must include designing and devel¬ 
oping vision sensor integrated robotic sys¬ 
tems that involve intelligent task planning 
and automated process planning to support 
intelligent manufacturing applications in 
unstructured/partially structured environ¬ 
ments. Apply at the Texas Employment 
Commission, Austin, TX, or send resume to 
the Texas Employment Commission, TEC 
Building, Austin, Texas 78778, J.O. 
#6421898. Ad paid by an equal employ¬ 
ment opportunity employer. 


UNIVERSITY OF PENNSYLVANIA 
Instructor in Computer and 
Information Science 

Applications are invited for an Instructor- 
ship position beginning July 1992. Respon¬ 
sibilities include preparing, teaching, over¬ 
seeing and coordinating introductory 
courses in the undergraduate program. The 
teaching load is the equivalent of three 
courses per semester, adjusted for time spent 
on laboratory and curriculum development. 
Contract period is two years, with the possi¬ 
bility of a one-year renewal. 

Candidates should have at least a Master’s 
degree in Computer Science, teaching ex¬ 
perience at the undergraduate level and 
familiarity with C, Pascal and Scheme (or 
Lisp). Familiarity with ML would be useful, 
but is not essential. Candidates should be 
able to demonstrate ability and strong in¬ 
terest in teaching undergraduates. Resumes 
and names of three references should be 

Dr .'Jean Gallier 
Chair, Faculty Recruiting 
Department of Computer and Information 

University of Pennsylvania 
Philadelphia, PA 19104-6389 

The University of Pennsylvania is an Affir¬ 
mative Action/Equal Opportunity Employer. 
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CALL FOR PARTICIPATION 


Scalable High Performance Computing Conference 
April 26-29, 1992 

Williamsburg Hilton, Williamsburg, Virginia 


The Scalable High Performance Computing Conference (SHPCC) is the successor to the Distributed 
Memory Computing Conference series. We define a scalable high performance architecture as an 
architecture that is likely to be capable of delivering a teraflop sustained performance in the relatively 
near future. SHPCC will focus on software being developed to make it possible to effectively exploit 
the coming generations of these architectures and on applications that require teraflop computational 
rates. Researchers will present work on developing or evaluating software tools such as compilers, 
programming environments, and debuggers, along with tools to monitor and tune performance. In 
addition, researchers in the areas of computational fluid dynamics and molecular dynamics will dis¬ 
cuss their experiences with scalable multiprocessors. 


Invited Speakers 

Dennis Gannon, University of Indiana, Performance Animation 
Harry Jordan, University of Colorado, Scalability of Data Transport 
Randy Katz, University of California Berkeley, High Performance I/O 
Dimitri Mavriplis, ICASE, Computational Aerodynamics with Unstructured Meshes 

Vendor Presentations 

Technical presentations concerning present and future products 

Panel 

Roy Pargas, Organizer, Educational Issues in Scientific Computing 

Half Day Tutorials on Sunday, April 26 

Ramesh Agarwala: Computational Fluid Dynamics on Parallel Machines 
Ken Kennedy and Joel Saltz: Languages, Compilers and Tools 
Horst Simon: Applications of Massive Parallelism 


Advance Program & Registration Information 
SHPCC ’92 

IEEE Computer Society 
1730 Massachusetts Ave., N.W. 

Washington, DC 20036-1903 
FAX (202) 728-0884 

irrr mMDI ITCD QOfMCTV THE INSTITUTE OF ELECTRICAL AND 

IEEE COMPUTER SOCIETY electronics engineers, inc. 






BOOK REVIEWS 


Editor: Alan Kaminsky, Rochester Institute of Technology, PO Box 9887, Rochester, NY 14623-0887 
(716) 475-5255; Internet ark@cs.rit.edu;Bitnet arkics@ritvax. 

Object-Oriented Design 


Peter Coad and Edward Yourdon (Yourdon Press, Englewood Cliffs, N.J., 1991, 


This slim companion to the authors’ 
previous collaboration, Object-Orient¬ 
ed Analysis (Yourdon Press, 1990), is 
a most welcome addition to the ob¬ 
ject-oriented literature. It will appeal 
, to students, practitioners, and manag¬ 

ers struggling to enter the world of 
object-oriented programming and to 
those already in it who want a trea¬ 
sure trove of useful techniques. 

The heart of the book is a very sim¬ 
ple and elegant insight about the ar¬ 
chitecture of object-oriented systems. 
The authors identify four components 
of an architectural model from their 
study of object-oriented designs, 
namely, the problem domain, human 
interaction, task management, and 
data management components. They 
address the design of each component 
type in separate chapters. Then they 
introduce the structured-design crite¬ 
ria of coupling and cohesion, and ex¬ 
tend them — for the first time as far 
as I know — to object-oriented de¬ 
signs. 

Obviously, coupling criteria can be 
applied to messages in the same way 
that they are traditionally applied to 
subroutines. Less obviously, the crite¬ 
ria can be extended to classes. Low 
coupling between objects implies that 
l the number and kind of messages sent 

or received from other objects should 
also be kept simple. Even more sub¬ 
tly, the criteria can be applied to eval¬ 
uate the inheritance structure. In this 
case, Coad and Yourdon suggest high, 


not low, coupling between classes as a 
design goal. 

This three-step application of cou¬ 
pling criteria can also be applied to 
coherence criteria by looking at the 
coherence of each service in a class, 
each class as a whole, and the inherit¬ 
ance structure. 

The book uses graphical class and 
object diagrams that are a seamless 
outgrowth of the diagrams presented 
in Object-Oriented Analysis. Object 
International Inc. offers automated 
support for drawing and checking the 
notation. In fact, the authors use the 
tool’s design to illustrate the applica¬ 
tion of their ideas. 

It may be impossible to gather all 
the useful techniques and design crite¬ 
ria for object-oriented systems into a 
single book, particularly when they 
are still being proposed and hotly de¬ 
bated; but some omissions here are 
worth pointing out. There are no de¬ 
tailed design guidelines. Such para¬ 
digms as the Smalltalk community’s 
MVC model can help tie the design 
together by explicitly describing the 
constraints and relationships between, 
say, the problem-domain and human- 
interaction components. The book 
also omits the pitfalls of designing 
classes for reuse — for example, con¬ 
flicting styles of validating arguments 
or handling errors. 

The authors’ recommendation of 
strong inheritance coupling seems to 
me to fly in the face of the so-called 


ISBN 0-13-630070-7,197 pp„ $33) 

Law of Demeter, which argues for the 
need to hide implementation secrets 
even from a class’s heirs. I feel the 
jury is still out on this issue, and I 
would have liked Coad and Yourdon 
to tackle it explicitly. 

I found the structure of the bibliog¬ 
raphy flawed. It is divided into prima¬ 
ry bibliography, secondary bibliogra¬ 
phy, reference publications, and 
related publications. Some of these 
sections also separate books from arti¬ 
cles. Since all references in the text 
are cited in exactly the same way, I 
sometimes had to look in as many as 
five sections before finding a refer¬ 
ence in a sixth. 

None of these points diminish my 
strong recommendation of this 
thought-provoking gem of a book. 
Some readers may find the four basic 
design components suspiciously simi¬ 
lar to current object-oriented technol¬ 
ogy, with its awkward gaps between 
the rich, commercially mature frame¬ 
works for graphical user interfaces 
and the poorer, more experimental 
handlers for tasks or persistent ob¬ 
jects. But these components are also a 
boon to organizing quite different de¬ 
sign concerns and techniques. I look 
forward to testing these wonderful 
new ideas on my next object-oriented 
design project. 

Alejandro Teruel 

Universidad Simon Bolivar 

Caracas, Venezuela 


Software Engineering with Abstractions 

Valdis Berzins and Luqi (Addison-Wesley, Reading, Mass., ISBN 0-201-08004-4, 624 pp., $35) 


In their preface, Berzins and Luqi 
note the difficulty of convincing new 
computer science students of the im¬ 
portance of systematic methods and 
formal specifications because of their 
experience in programming on a rela¬ 
tively small scale. Certainly, the wide¬ 
spread availability of personal com¬ 
puters and cheap compilers gives 
many new students the sense that they 
already know what software develop¬ 
ment is, sometimes even better than 
their professors. They think of it as 
programming or, even worse, coding. 


The basic goal of this textbook for 
an advanced one-year course in soft¬ 
ware engineering is to demonstrate 
the use of modern formal methods. 
The authors emphasize approaches 
amenable to computer assistance. 

They concentrate on “a consistent 
treatment of the entire software de¬ 
velopment process and strive to 
present a single approach with suffi¬ 
cient depth to let the readers carry out 
the process, with concern on compati¬ 
bility and integration, rathfer than a 
broad survey of popular techniques.” 


To support this approach, they use 
Spec, a formal specification language 
that they introduced in earlier works. 
“Spec can specify the behavior of 
three different types of software mod¬ 
ules: functions, machines, and types. 
These modules can interact via three 
types of messages: normal messages, 
exceptions, and generators.” Modules 
and messages form a set of primitives 
that can express all common software- 
component properties. 

The semantic basis for Spec is the 
event model with its primitives of 
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modules, messages, events, and 
alarms. Spec reputedly has features 
for parallel, distributed, and real-time 
systems, although I have not used it 
and cannot confirm these claims. It is 
based on second-order temporal logic 
and allows writing specifications with 
Ada in mind. The entire book is 
heavily oriented toward Ada. A uni¬ 
fied graphical notation is an important 
part of this approach. 

The authors also emphasize the use 
of tools and suggest using their own 
software for Spec, which they say is 
available from the Open Software 
Foundation. Honestly, tools are what 
software engineering classes need. 
Most of the courses I know are closer 
to a paper-and-pencil model than to 
the real development environment 
that students will meet in their first 
jobs. The only problem I had with the 
book in this respect was that roughly 


40 percent of its body is program list¬ 
ings. This looks incomprehensible; I 
would suggest making the code avail¬ 
able via file transfer protocol (ftp). 

The book’s structure is almost ideal 
for teaching software engineering. 
Five chapters address the five phases 
identified in the software develop¬ 
ment process: requirements analysis, 
functional specification, architectural 
design, implementation, and evolu¬ 
tion. Each of these chapters presents 
goals, basic concepts, procedures and 
guidelines, and a progressive descrip¬ 
tion of the case study, as well as a sur¬ 
vey of quality assurance issues and 
project management aspects for each 
phase. 

Virtually every aspect of software 
engineering is touched upon, includ¬ 
ing configuration management, docu¬ 
mentation, verification and valida¬ 
tion, and software maintenance. 


Only the use of standards has not 
been emphasized as much as I would 
like. 

The book develops one long exam¬ 
ple through the text: an airline reser¬ 
vation system. This vehicle illustrates 
most of the concepts, but ties an in¬ 
structor to the authors’ order of pre¬ 
sentation, which might pose problems 
in an actual course. 

I can hardly think of a better, more 
consistent textbook on software engi¬ 
neering. It seems very likely, given the 
book’s emphasis on formal methods 
and the availability of software sup¬ 
porting the Spec language, that this 
will become one of the most frequent¬ 
ly used textbooks in software engi¬ 
neering courses. 

Janusz Zalewski 

Southwest Texas State University 

San Marcos, Texas 


Software Shock: The Danger and the Opportunity 

Roger S. Pressman and S. Russell Herron (Dorset House Publishing, New York, 1991, ISBN 0-932633-20-X, 226 pp., $18.95) 


The purpose of the book, as stated 
in the preface and introduction, is to 
help people understand the impor¬ 
tance of software to our society by ex¬ 
amining its shock potential. In trying 
to reach all audiences, the uninitiated 
to the initiated, the authors have suc¬ 
ceeded only in presenting a confused 
and incoherent view of software and 
its effect on our lives. 

Many of the examples of runaway 
software, misused software, and ex¬ 
pectations from new software systems 
are from the past. There is little or no 
interpretation of what software shocks 
the future holds or how to deal effec¬ 
tively with them. 

Only two chapters actually focus on 
the components of software shock. In 
Chapter 2, the authors try to identify 
products and processes that will be 
controlled by software in the 21st cen¬ 
tury, but they fail to demonstrate the 
stress and disorientation this will 
cause individuals and groups. In 
Chapter 3, they try to infer the “or¬ 
thogonal connections” between soft¬ 
ware and society in areas such as drug 
dependency, communications, and 
psychology. This look into the future 
would have been more enlightening if 
it had included more information 
about the functional fields under dis¬ 
cussion. For example, in the discus¬ 
sion of artificial reality, how is soft¬ 
ware used today in diagnosing and 
combating drug addiction? How can 
software mimic high-order brain func¬ 


tionality? What trends does actual 
field research suggest? In many in¬ 
stances, the authors fail to raise key 
questions that must be answered be¬ 
fore software can be committed to 
make the orthogonal connection a re¬ 
ality. 

The majority of the book focuses on 
subjects normally found in introducto¬ 
ry texts — who are the programmers, 
when was the computer developed, 
how did computer languages evolve, 
and so on. The problem with these 
sections is twofold: first, the material 
is dated, and second, it does not live 
up to the book’s intended purpose. 

For example, in the discussion of 
the Strategic Defense Initiative, the 
authors carry on about the number of 
lines of code and the possible errors 
that could occur in producing the soft¬ 
ware. This information has been pub¬ 
lished in one form or another since 
1985. What would have been more ap¬ 
propriate in a book about software 
shock is the cost of developing the 
code, not in terms of dollars but in ex¬ 
pended resources. How many pro¬ 
grammers? What languages? What 
type of interfaces? How will diverse 
systems be integrated? What do errors 
cost in terms of human discomfort or 
loss? Is there a correlation between 
the number of lines of code and the 
complexity of the job? People unfa¬ 
miliar with the software business need 
to know what the numbers mean if 
they want to participate more fully in 


the debate about developing extreme¬ 
ly large systems. 

In discussing the historical develop¬ 
ment of hardware and software, the 
authors use terms like Unix as if ev¬ 
eryone knows what they mean. Then 
they omit the shocks that system users 
might have if Unix malfunctions. 

Other notable absences from the 
discussion of software’s future include 
the role of standards in software defi¬ 
nition, development, testing, and im¬ 
plementation; the role of functional 
specialists in the development pro¬ 
cess; the transition from stepwise wa¬ 
terfall development to rapid applica¬ 
tion development to the newer spiral 
process, and the resultant impact on 
the quality of the software systems; 
the rise of fourth-generation languag¬ 
es; and the impact of the migration to 
computer-aided systems and software 
engineering tools and automated code 
generators. 

From its title we expect this book to 
tell us how software is misused and 
underused in our society today and 
how it can be harnessed for our fu¬ 
ture. One would expect a vision that 
addresses the cost of software in terms 
of. dollars, resources, and productivity. 
This book is neither visionary nor ex-\ 
planatory and cannot be recommend- 1 
ed for academic or casual reading. 

Chadwick H. Nestman 

RJO Enterprises, Inc. 

Lanham, Maryland 
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THE CHANNEL 


Editor: Will Tracz, IBM, Federal Sector Division, Mail Drop 0210, Owego, NY 13827 
e-mail tracz@owgvmO.vnet.ibm.com 


How to forestall electronic mutually assured destruction 


What do nuclear weapons, political 
leaders, billionaires, and massively 
parallel processing systems have in 
common? Excess capacity, power, or 
resource — just too much! 

As a society, the United States has 
hot lines and treaties to minimize the 
likelihood of a nuclear conflict, elec¬ 
tions to oust unethical and unrespon¬ 
sive politicians, and the Securities and 
Exchange Commission to regulate 
financial mavericks. These controls 
and others, like the US Constitution, 
exercise and implement checks and 
balances meant to prevent societal 
chaos. 

Technology, however, advances at a 
dizzying pace, and few controls gov¬ 
ern the innovative spirit and thought 
process. Massively parallel processors 
(MPPs), the newest fad in computa¬ 
tion, pose a serious threat to the 
safety of electronically dependent 
societies if criminal organizations or 
terrorist groups acquire the smarts to 
manipulate them. 

Computers are everywhere: in the 
telephone system, the banking system, 
your car, your VCR. The electronic 
brotherhood of silicon embodied by 
computer technology has achieved 
trusted ubiquity, created jobs, and 
generated substantial tax revenue in 
the process. 

The US government has invested 
heavily in the electronics industry, pri¬ 
marily for national defense. As a by¬ 
product of this investment, the US is 
now the global leader in MPPs and re¬ 
search. This means that the US gov¬ 
ernment maintains a new strategic 
threat in addition to the existing nu¬ 
clear, chemical, and biological stock¬ 
piles. 

The technology to construct MPPs 
is widely available. The microproces¬ 
sor in your personal computer, when 
replicated a thousand times or more 
and connected through a communica¬ 
tion network, is all that is needed to 
physically build an MPP. 

Any technically cognizant, educated 
person can construct an MPP from 
off-the-shelf technology. MPP stock¬ 
piles, like their nuclear counterparts, 
threaten not only enemies of the US, 


but the nation’s allies as well, with an 
equally frightening form of mutually 
assured destruction which can be un¬ 
intentionally sparked by a simple soft¬ 
ware bug. Electronic mutually assured 
destruction (EMAD) will not instan¬ 
taneously level cities, obliterate mil¬ 
lions of citizens, poison the food sup¬ 
ply, or start a nuclear winter, but the 
catastrophe arising from an assault on 
our electronically dependent ad¬ 
vanced civilization could be equally 
devastating. 

The key to any computer lies in the 
software, the controlling agent that di¬ 
rects the machine to conduct work on 
behalf of a human being or organiza¬ 
tion; computers are worthless space- 
heaters without it, and MPPs are no 
exception. 

When software works for the com¬ 
mon good, almost everyone profits; 
when it stops working, there is hell to 
pay because nothing linked to it 
works. Software used with criminal in¬ 
tent would be catastrophic. Even acci¬ 
dental software problems — bugs — 
cause serious mishaps, and some inci¬ 
dents are more common than anyone 
desires: air-traffic controllers are driv¬ 
en nuts by false collision signals gen¬ 
erated from faulty collision-avoid¬ 
ance-system software, computer 
viruses jam computer networks, long¬ 
distance telephone service fails, X-ray 
radiation therapy machines sometimes 
“cook” people because the dosage 
control software is bad, and so on. 

It doesn’t take a great leap to esti¬ 
mate the impact of insidious and crim¬ 
inal computer software applications, 
like those that may be designed to 
crack data-encryption codes used by 
banks to protect electronic financial 
transactions. An MPP running encryp¬ 
tion-cracking software could virtually 
destroy the global financial structure. 
In the blink of an eye, billions of dol¬ 
lars in assets could be illegally trans¬ 
ferred! 

When correctly programmed, the 
power contained in an MPP can in¬ 
stantaneously accomplish this task 
with ease. Even more spectacular and 
visible acts of terrorism are possible. 

The Exxon Valdez oil spill of 1990 


could become a daily event, or the 
Aeromexico mid-air collision of 1986 
over Cerritos, California, could be re¬ 
peated in dozens or hundreds of plac¬ 
es simultaneously. All you would need 
to do is program an MPP to tap into 
the global positioning satellite systems 
used for navigation and feed mislead¬ 
ing navigational signals to the ship or 
airplane while disrupting the vessel’s 
electronic radar control software. 

But the US government is not myo¬ 
pic, and it is studying ways to prevent 
these events from happening. The US 
National Security Agency, the CIA, 
and the armed services have research 
programs under way to prevent the 
pernicious and willful implantation of 
hostile electronic software agents into 
computer systems. However, if their 
work fails, the next cruise missile 
bound for Baghdad might wind up in 
Tel Aviv. The Chinese military is ac¬ 
tively researching ways to protect its 
electronic and computer-based de¬ 
fense systems from assault and intru¬ 
sion by electronic bugs. The US is for¬ 
tunate that its enemies — for the 
moment — are less technologically so¬ 
phisticated and have not seen the eco¬ 
nomic wisdom of teraflop techno¬ 
terrorism. 

So long as we continue to create 
increasingly sophisticated and power¬ 
ful computer systems and the software 
to exploit them, the possibility of a 
serious and crippling assault on our 
electronic societal infrastructure will 
become more likely. A technology 
reduction and control treaty 
(TRACT) is needed to limit the 
spread of electronic technological 
threats and lower the probability of a 
computerized first strike. But the 
technology arms race juggernaut is 
under way, and only globally united 
effort can rein it in. The US should 
appeal to the United Nations to create 
an international technology agency 
that will monitor non-compliant and 
criminally predisposed nations so they 
can't launch teraflop weapons of elec¬ 
tronic terror. 

Richard Marlon Stein 

Santa Clara, California 
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connect four peripherals and a complete set of LiSBUS'*" 
Software Development Tools to create custom applica¬ 
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